Как вариант, для упрощения можно все эти статические классы сделать абстрактными, в них содержать общую логику (дабы не копипастить), а их наследовать вложенными классами
Если мне память не изменяет, то ASIO это в принципе имеет смысл только для винды т.к. в маках и линуксах отсутствует механизм, который обходится ASIO, соответственно asio и не нужен.
Винил — это некий способ прикоснуться к истории.
CD не настолько стары, не являются символом истории звукозаписи. Да, винил был не первым, но достаточно значимым.
Опять же, в виниле, обложке к нему, проигрывателе есть определённая неидеальность, которую мы любим.
Такой вот ретро-фетиш.
Динамический UI — вещь полезная, но пример, в который она обернута далёк от того, в каких случаях стоит использовать его. Правильный пример работы можно подсмотреть в RectTransform'е (посложнее), LayoutElement'е (попроще) и т.д., которые входит в Unity UI. Если не понятно как это сделано у них (хотя там всё в общем-то очевидно), благо есть исходники, которые можно посмотреть здесь bitbucket.org/Unity-Technologies/ui или же декомпилировать Visual Studio (если включена настройка декомпайла) (я пользуюсь этим вариантом ибо быстро).
Простите, но статья даже не бесполезная, а вредная ибо новички сейчас начитаются этого и начнут делать также.
То, что у вас возникла ситуация необходимости такого подхода говорит о фиговости архитектуры и надо эти проблемы решать так, как описал BasmanovDaniil выше т.е. через возможности, которые нам щедро предоставляет ООП — интерфейсы, наследование и пр.
И да, почему минусанули gturk'а вверху, ведь он в чём-то прав по поводу God object'а — подход автора — это прямой путь к нему.
Всё, что описал автор можно понять прочитав доку по эдитор-скриптам
Юнити является достаточно широкой в плане возможностей и объема материала платформой, достаточно объемная документация тому доказательство.
Это вполне позволяет указывать junior/middle/senior unity3d developer. Если вам так удобно, то можно Senior C# Unity3d Developer (хотя C#, имхо, априори в серьёзной разработке под юнити).
З.Ы. А вообще, холиварщина обычная. Не принципиально
С такой логикой можно говорить, что мозги используются для разработки веб-приложений.
Эти вещи нельзя сравнивать, а если и пытаться, то адекватного вывода получить нельзя
Как вариант, для упрощения можно все эти статические классы сделать абстрактными, в них содержать общую логику (дабы не копипастить), а их наследовать вложенными классами
Разница в том, что если наловить до усилителя, то усилитель усилит помимо полезного сигнала еще и помехи
плюсы и минусы остались на отпиленном нампаде
Вам еще раз и ответим. Шаблоны, которые generic. Ближайший аналог — плюсовые шаблоны, хоть и урезанные
CD не настолько стары, не являются символом истории звукозаписи. Да, винил был не первым, но достаточно значимым.
Опять же, в виниле, обложке к нему, проигрывателе есть определённая неидеальность, которую мы любим.
Такой вот ретро-фетиш.
Частным случаем ООП является «Прототипное программирование». Оно и есть в JS.
То, что у вас возникла ситуация необходимости такого подхода говорит о фиговости архитектуры и надо эти проблемы решать так, как описал BasmanovDaniil выше т.е. через возможности, которые нам щедро предоставляет ООП — интерфейсы, наследование и пр.
И да, почему минусанули gturk'а вверху, ведь он в чём-то прав по поводу God object'а — подход автора — это прямой путь к нему.
Всё, что описал автор можно понять прочитав доку по эдитор-скриптам
Это вполне позволяет указывать junior/middle/senior unity3d developer. Если вам так удобно, то можно Senior C# Unity3d Developer (хотя C#, имхо, априори в серьёзной разработке под юнити).
З.Ы. А вообще, холиварщина обычная. Не принципиально
Эти вещи нельзя сравнивать, а если и пытаться, то адекватного вывода получить нельзя