Ой да! Действительно это косяк с моей стороны. Я знал, что многие классы в UnityEngine наследуются напрямую от Component и думал это разрешено и для пользовательских типов, но я ошибался. В скором времени отредактирую этот момент.
Спасибо за полезную информацию! Да, с ConfigureServices и ConfigureContainer сталкивался, но не так много работал с ASP, чтобы отложилось в голове, что они тоже не оверрайдят и не имплиментируют ничего. Да, наверно я немного не так выразился. Конечно, есть рефлексия и Linq.Expressions, и они действительно активно используются в самых разных фреймворках. Наверно правильно бы было подчеркнуть более явно, что в Unity есть именно своя система для того, чтобы делать подобные вещи без рефлексии.
Ну уж я бы так не принижал архитекторов Unity=) Думаю в ООП они что-то да понимали, да и C# не со лба взяли скорее всего, а имея определенное представление о том, что это за язык. Ну тут даже правильнее будет сказать, что смотрели не на сам C#, а на Mono в те времена. Ну а получилось, что получилось. И получилось не так плохо. C# в Unity действительно пахнет плюсами больше, чем в .NET, преимущественно из-за более активного навязывания RAII-подобных конструкций. Но и в стандартной библиотеке C# IDisposable никто не отменял. Да и что уж там говорить... указатели, StructLayoutAttribute, маршалинг, Span... C# сам по себе не так уж далек от плюсов, если действительно остро встает вопрос о производительности. И даже в .NET мире можно найти код который будет в 1000 раз ближе к плюсам, чем среднестатистический код на Unity.
Да, именно эту цель и преследовали разработчики Unity3d. Сделать минимальный порог входа в движок. По этой же причине в качестве скриптовых ЯП были выбраны C# и UnityScript(аналог JavaScript, который не прижился и ушел в небытие несколько лет назад), а не C++ на котором написан сам движок или Lua, который активно используется в геймдеве, но не так распространен на рынке IT. Размышляя об этом я как раз таки вижу проблему UnityScript в том, что он был слишком уж далек от правил столетних дедов и не подходил для разработки даже небольших проектов(что уж говорить про серьезный энтерпрайз), так как предоставлял слишком много свободы для написания плохоподдрерживаемого кода. C# в свою очередь, с учетом того, что Unity Technologies действительно сделали его чуть ближе к скриптовым языкам с помощью приколов компиляции и очень свободного API попал в золотую середину. Писать на нем в Unity3d достаточно просто, чтобы решить большинство прикладных игровых задач без выстраивания какой-либо вменяемой архитектуры, которую можно инужно будет поддерживать. При этом вся мощь построения архитектуры для больших и сложных масштабируемых систем тоже никуда не делась. Конечно пытаясь угодить противоречивым концепциям будут образовываться "швы" в архитектуре, но Unity Tech, как мне кажется, хорошо справились с задачей. Главное правильно определить какой тип проекта вы хотите делать. Микроприлагу на 1-2 разработчика, на которую забьете через год, или долгоиграющий проект на команду 100+ человек, или что-то по середине. От этого зависит какие правила взаимодействия с Unity API и поддержания качества кода выстраивать и нужны ли они вообще. Надеюсь не слишком душно ответил.
Безусловно. При большинстве кейсов использования пуллинга объектам нужны методы для переключения состояния при возвращении в пул и взятии из пула. Но конструкторы тут ни при чем. Концепция конструирования объектов в ООП никак не связана с пуллингом или его отсутствием. Отсутствие конструкторов для компонентов в Unity3d это сложный вопрос связанный с ограничениями архитектуры самого движка и сомнительными решениями в проектировании API, а не с тем, что разработчики привыкли использовать тот или иной паттерн. Это то, что я пытаюсь сказать.
Есть такое=) Я бы, конечно, не драматизировал слишком сильно. Работать можно и даже часто удобно. Просто надо смириться, что C# для Unity это чуть-чуть не то же самое, что обычный C#. Не сильно. Просто надо знать о некоторых мисконсепшенах и подводных камнях. Я для этого и написал эту статью) У меня раньше пригорало от этого. Но когда начал относится к программированию в Unity менее догматично и больше фокусироваться на том, как эффективнее и чище писать код именно с учетом того, что Unity не идеален, мне стало на много легче и приятнее работать с движком.
При AddComponent или добавлении компонента в редакторе никакой пуллинг не используется. При обычным пулинге в .NET(и в Unity с обычными C# классами) приложениях вам никто не запрещает использовать конструкторы. Все таки перед тем, как положить объект в пулл, его надо создать, и все здоровые люди делают это через конструкторы(явно или через DI).
Спасибо за фидбек. Сам не сильно разбираюсь в тонкостях разницы GC на Unity и .NET, так что с удовольствием почитаю статью.
Да, про UI в Unity думаю еще 5-7 отдельных статьи можно написать, так что решил его тут вообще не трогать=)
К сожалению не разбираюсь в этом достаточно глубоко, чтобы сгенерировать какие-нибудь полезные и/или интересные заметки по этому поводу.
Ой да! Действительно это косяк с моей стороны. Я знал, что многие классы в UnityEngine наследуются напрямую от Component и думал это разрешено и для пользовательских типов, но я ошибался. В скором времени отредактирую этот момент.
Спасибо за полезную информацию! Да, с ConfigureServices и ConfigureContainer сталкивался, но не так много работал с ASP, чтобы отложилось в голове, что они тоже не оверрайдят и не имплиментируют ничего. Да, наверно я немного не так выразился. Конечно, есть рефлексия и Linq.Expressions, и они действительно активно используются в самых разных фреймворках. Наверно правильно бы было подчеркнуть более явно, что в Unity есть именно своя система для того, чтобы делать подобные вещи без рефлексии.
Ну уж я бы так не принижал архитекторов Unity=) Думаю в ООП они что-то да понимали, да и C# не со лба взяли скорее всего, а имея определенное представление о том, что это за язык. Ну тут даже правильнее будет сказать, что смотрели не на сам C#, а на Mono в те времена. Ну а получилось, что получилось. И получилось не так плохо. C# в Unity действительно пахнет плюсами больше, чем в .NET, преимущественно из-за более активного навязывания RAII-подобных конструкций. Но и в стандартной библиотеке C# IDisposable никто не отменял. Да и что уж там говорить... указатели, StructLayoutAttribute, маршалинг, Span... C# сам по себе не так уж далек от плюсов, если действительно остро встает вопрос о производительности. И даже в .NET мире можно найти код который будет в 1000 раз ближе к плюсам, чем среднестатистический код на Unity.
Спасибо, приятно слышать! Я бы такую статью из параллельной вселенной с удовольствием бы почитал=)
Спасибо! Да, про transform действительно не знал) Надо будет отредактировать
Да, именно эту цель и преследовали разработчики Unity3d. Сделать минимальный порог входа в движок. По этой же причине в качестве скриптовых ЯП были выбраны C# и UnityScript(аналог JavaScript, который не прижился и ушел в небытие несколько лет назад), а не C++ на котором написан сам движок или Lua, который активно используется в геймдеве, но не так распространен на рынке IT.
Размышляя об этом я как раз таки вижу проблему UnityScript в том, что он был слишком уж далек от правил столетних дедов и не подходил для разработки даже небольших проектов(что уж говорить про серьезный энтерпрайз), так как предоставлял слишком много свободы для написания плохоподдрерживаемого кода. C# в свою очередь, с учетом того, что Unity Technologies действительно сделали его чуть ближе к скриптовым языкам с помощью приколов компиляции и очень свободного API попал в золотую середину. Писать на нем в Unity3d достаточно просто, чтобы решить большинство прикладных игровых задач без выстраивания какой-либо вменяемой архитектуры, которую можно и нужно будет поддерживать. При этом вся мощь построения архитектуры для больших и сложных масштабируемых систем тоже никуда не делась. Конечно пытаясь угодить противоречивым концепциям будут образовываться "швы" в архитектуре, но Unity Tech, как мне кажется, хорошо справились с задачей. Главное правильно определить какой тип проекта вы хотите делать. Микроприлагу на 1-2 разработчика, на которую забьете через год, или долгоиграющий проект на команду 100+ человек, или что-то по середине. От этого зависит какие правила взаимодействия с Unity API и поддержания качества кода выстраивать и нужны ли они вообще. Надеюсь не слишком душно ответил.
Безусловно. При большинстве кейсов использования пуллинга объектам нужны методы для переключения состояния при возвращении в пул и взятии из пула. Но конструкторы тут ни при чем. Концепция конструирования объектов в ООП никак не связана с пуллингом или его отсутствием. Отсутствие конструкторов для компонентов в Unity3d это сложный вопрос связанный с ограничениями архитектуры самого движка и сомнительными решениями в проектировании API, а не с тем, что разработчики привыкли использовать тот или иной паттерн. Это то, что я пытаюсь сказать.
Есть такое=) Я бы, конечно, не драматизировал слишком сильно. Работать можно и даже часто удобно. Просто надо смириться, что C# для Unity это чуть-чуть не то же самое, что обычный C#. Не сильно. Просто надо знать о некоторых мисконсепшенах и подводных камнях. Я для этого и написал эту статью)
У меня раньше пригорало от этого. Но когда начал относится к программированию в Unity менее догматично и больше фокусироваться на том, как эффективнее и чище писать код именно с учетом того, что Unity не идеален, мне стало на много легче и приятнее работать с движком.
При AddComponent или добавлении компонента в редакторе никакой пуллинг не используется. При обычным пулинге в .NET(и в Unity с обычными C# классами) приложениях вам никто не запрещает использовать конструкторы. Все таки перед тем, как положить объект в пулл, его надо создать, и все здоровые люди делают это через конструкторы(явно или через DI).
К счастью, Unity Technologies пересмотрели свою политику монетизации и значительно облегчили бремя пользователей.
Не знал. Спасибо за совет!