Тут вопрос чем именно ломается. Изменение в логических операторах или последовательностях всё же много чаще, чем изменение принципов. А это как раз ломает уже построенную архитектуру ECS. И такое изменение может потребовать проработки всей группы из-за высокой связности. Тут уже писал, имхо, ECS хорош как раз там, где такой сложной логики нет, а классификация вообще не требует последовательного выполнения. Но не редко сложная логика в таком виде приводит к дополнительным вычислениям и данным, дабы реализовать те же условия логики как часть данных.
Так, многие и про *-варианты не слышали) Тут знать терминологию не надо, чтобы понять суть. А она вообще в другом
Любая новая когнитивная деятельность поначалу неудобна) ECS так же поначалу часто неудобен почти для всех, не важно что там с ООП. Да даже само по себе программирование то ещё неудобство)
В таких вещах хорошо смотреть как удобно это читается, чинится, изменяется. И вот в первых двух неудобств у ООП нет вовсе. Изменения посложнее, но если не требуют перепроектирования, то так же крайне просты. И, что не маловажно, изменения совпадают с дизайном(ТЗ) большинства людей.
Это не пример выжившего лётчика, а как раз вполне обыденный. Если убрать шелуху, которую присваивают постфактум людям, то можно заметить, что как раз выбивающиеся из правил двигают что-то в мире, в т.ч. науку. А из "отличников" % таких людей ни чуть не отличается, хотя у них часто куда лучше среднего стартовые возможности и доступ к лучшему образованию.
Там выше человек писал, о том как было бы замечательно провести сегрегацию людей по школьным знаниям. Принудительно
Когда у тебя объекты из РПГ, где каждый имеет свою особую логику, то легко увидеть, что SIMD работает на 1-2 объектах, а дополнительные цепочки вызовов функций на порядок больше, потому как создаётся огромное кол-во классов с ~1 логическим действием.
Про критику не соглашусь. В некоторых случаях порядок не важен и так можно выстраивать архитектуру - это лучший способ. Но так не всегда получается, и тогда нужно иметь чёткий порядок. А если не получается в условиях типа case в ООП, то нужно вводить дополнительные переменные и делать лишний прогон. Да и в целом, как задать порядок в сложной логике, которая описывается несколькими документами? Я тут не на столько компетентен, но сейчас подозреваю, что лучше вводить булевы переменные для таких случаев, а не контролировать порядок явно. А это падение производительности, но сильное упрощение проектирования.
О какой эффективности проходов по данным говорить, если контроллер требует действий над 1-10 объектами? Тут не то, что SIMD, тут вообще такое выполнение убивает эффективность использования кеша проца, и особенно предсказаний. А где прям много объектов, ну хотя бы 1к+, выигрыш действительно существенный. Но много ли таких ситуаций? До ECS такое решали просто - массивчик, проход по нему внутри цикла. И тот же SIMD можно обеспечить. Хранить и пользоваться такими данными сложно, но часто это конечная логика для C# кода, так что можно было и без ECS запустить 10к юнитов с анимацией на Unity PC. Схожим образом, например, работают(или работали) партиклы.
Про "гибко и безопасно управлять логикой" вообще мимо. Именно с логикой(условиями), у ECS прям проблемно. Перелопатить кучу данных - это да, легко. А вот управление логикой разбивается на кучу частей, которые могут очень неожиданно отработать. Фрагментация логики приводит к неожиданному поведению систем в целом. Что уж, порой без некоторых новых инструментов отладки это было вообще не реально. Хотя иногда это даже в плюс, но не когда требуется чёткое поведение. И тем более, не когда читаешь код и тебе человеки говорят о баге, а ты ещё и не знаешь с сотню систем которые затрагивают это место.
По мне так ECS хороша для какой-нить RTS в части логики юнитов, рендеринга в целом и им подобных. Т.е. где все действия ограничены и почти не содержат условий в принципе или условия сами проистекают из их особенностей(классификации).
Юзкейсы из чистой архитектуры. DDD про другое, хотя те же юзкейсы можно сказать там есть в Application Layer. Смешивать эти 2 подхода странно. Но применение в таком виде это уже за гранью обоих этих подходов) В обоих случаях БЛ должна быть в модели, в ЧА собсно модель, а в DDD это разные части доменного слоя, как аналог модели это сущности и их агрегаты
В играх часто выходит очень сложная логика, которая не редко умещается буквально в несколько доменов, а то и в 1. Т.е. DDD там по этой же причине толком не применяется - излишне. Чистая архитектура примерно то же самое, хоть она попроще, поменьше, всё равно слишком избыточна. Общие подходы с разделением на схожие части и связи в хороших проектах есть всегда и +- соответствуют этим 2, только без бойлерплейта. Тут почаще можно встретить MVC, например, ну или MVVM. Этого разделения + чуть-чуть смысла, и часто хватает за глаза. Основная сложность всё равно остаётся внутри логики
В цикле статей(маг и воин, 5 частей) такое наследование как раз и должно быть. Он в 5 части раскрывает как это сделать без боли, точнее почему это работает и в чём ошибка была. Но примера в коде не даёт
15-20 лет назад про ООП много говорили. И почти никто не умел. Я это понял чутка позже. Сам я писал вначале в процедурном стиле. Первые компроекты вообще целиком процедурками были. Лет 5-15 назад я прям смотрел на проекты и видел Успешные проекты в геймдеве именно в процедурном стиле. Много видел разговоров про ООП и тп., а проект всё те же процедурки, но с финтифлюшками, функциональщиной, реактивщиной и т.п.. Последний такой видел в распространённой мидикорке или казуалке с прокачкой особняка и т.п. До асинков и аналогов ещё часто встречал колбечное программирование - отдельный вид мазохизма, который, к счастью, совсем почти вымер. Это не как ООП в C# с event-based в норме в то время, или промисами java, а часто именно процедурный стиль
Так вот даже тот последний проект в процедурном держал дубли кода, тащил кучу зависимостей, контроллеры пухли очень сильно и разбираться в этом было так сложно, что разрабы тупо забивали на поиск кода(сотни или тысячи строк сильносвязного кода в 1 классе). Логика была размазана в контроллере, из-за чего происходила циклическая правка багов. Но логика не была размазана между контроллерами, легко было отследить что откуда стартует и что изменяет, и в целом была на месте. Т.е. изначально проект грамотно спроектировали. Только в целом понять как оно работает было почти невозможно, не разбирая код по кирпичику до самого основания. Потихоньку сконвертили многое в ООП и проблема с пониманием как работает та или иная вещь полностью ушла - это стало легко посмотреть прямо в коде, не спрашивая дизайнеров о том, что делали пару лет назад люди, которых уже давно нет. Зависимостей так же стало в разы меньше.
Многие из процедурного так и "не выросли". Не знаю, может даже большинство. Я на собесах ни разу не встречал вопросов о проектировании, например. Инструменты ООП - этого полно. А вот как их применять - почти и не помню такого. Впрочем, по паттернам так же. Вопросы о паттернах есть, а об их применении, условиях, последствиях - нет. Сами собеседующие часто не особо шарят. И сам когда спрашиваю, да хотя бы об алгоритмах, редко кто может сказать про общие принципы, хотя за плечами бывает явно не плохой бек и не мало проектов.
Про 10 классов - это как раз часто не смогли, кроме некоторых случаев подходов, типа интерфейс как контракт
Флаг именно в таком виде, если он не нужен в ECS, может так же реализовываться в ООП. Конкретно указанный случай скорее некорректен, т.к. его быть в целом не должно.
Ну да, планировать надо. В ECS тоже. Только сам ECS подталкивает к этому. Но есть момент, что когда логика становится сложной, то наборы правил тоже становятся очень сложными. Как и отслеживание логики и последовательности изменения состояния. И часто это много сложнее чем в ООП, потому как логика действия и изменения данных проходят большие цепочки контроллеров. Чуть ошибёшься в очерёдности, не добавишь для её контроля и тп - всё поломается. Кстати, и производительность такого кода много меньше, чем в ООП.
Чистые данные без методов - это не про функциональщину) Там, пусть и условно, всегда есть методы для каждого состояния и они как раз условно содержат состояние, точнее меняют текущее. Но и выполняются они не такими группами и позволяют менять состояние целиком. А так можно и ООП назвать похожим, там тоже есть данные и применяемые к ним методы, прям как в FP, но уже есть "сайдэффекты". Всё таки разница в подходах по сравнению с DOP огромна в обоих случаях, и ещё больше в вариантах для Unity
Штраф будет, т.е. его выпишут без твоего на то желания. Дальше только в суд. А судьям всё равно) По этой статье и до ВС доходили не раз, но туда далеко не все дела желающих попадают на рассмотрение. И судьи, как правило, не смотрят такие дела, просто за глаза вынося решения.
Ни капли не выше, если вы в биологии на школьном уровне разбираетесь и можете хотя бы не много разобраться в ответах. Разницы между случайным врачом и гуглом просто нет при случайном же заболевании, даже если не разбираешься более глубоко. К сожалению, сейчас такова действительность
Врач скорее будет лучше только в некоторых обстоятельствах, например, заболевание типичное для местности или качеств больного, специфично для опыта врача, при ведении больного длительное время, и прочих подобных случаях
Зависит от правил и структуры игры. Выделение памяти для любого мидла в геймдеве решить не проблема. Массивы-списки это ещё не плохо. Сейчас не редко реактивку пихают. Поля ID вообще тут при чём? Обычно это появляется при подключении БД.
Геймдев уровня mov [edx],ebx умер больше 30 лет назад. На уровне движков в случае особых оптимизаций это ещё можно встретить, и то, не мала вероятность что за такой код тебя побьют. И правильно, т.к. компиляторы не плохо работают.
Флаги и проверки посреди, в стиле, а всё ли ок с данными, их надо отсортировать, проверить вообще есть ли подходящие и т.д. - признак плохого проектирования в ООП.
Монструозные циклы не редко то же самое) Но тут не всегда, иногда всё же бывают большие циклы, но скорее там, где надо сложную обработку данных и быстродействие, например, обработку мешей.
А, ну и ECS с функциональщиной ничего общего не имеет. По структуре методов это считай процедурка. Вероятно, тебе проще структурировать информацию в ECS. В таком подходе это структурирование является обязательной частью работы, поэтому её не пропустишь - код вообще не будет правильно работать. В ООП в некотором роде схоже нужно структурировать, но можно забить и писать в процедурки
Что мешает без RX на эвентах то же самое сделать? А чтобы проще была сортировка сделать с аргументом по хешу. И тогда кто угодно сможет подписаться и получать данные. Правда, обработка будет идти параллельно, если подписчика 2. Но там уж можно как угодно вертеть под свои нужды
Не сарказм ли это? 90% связующего кода и 10 логики - это прям эталон того, что делается что-то не так.
И это как раз очень плохой код на больших системах, который ещё и разрастается быстро и бесконтрольно. Как минимум, в нём всегда будет ещё много-много строчек кода условий, которые будут говорить как именно перемножать и надо ли это вообще делать, так же там появятся досрочные выходы, и выходы посреди метода(break посреди циклов и return посреди и в начале метода). Это всё как раз ошибки проектирования в OOP. В норме (почти) не должно быть выходов посреди методов, лишних связей, как и управляющих объектов так же минимально - логика внутри объекта.
Я уже десятки команд встречал и соглашусь насчёт ECS полностью. Простые действия в несколько строк в COP(OOP) делаются через создание нескольких файлов. ECS был бы удобен именно как внутренний слой в циклах обработки - почему так не сделали с теми же MB совсем не понимаю.
В большинстве случаев, когда говорят о том, что в ООП плохо, не получается и т.д, и тп = команды просто не могут в ООП. Не могут заранее спроектировать и поддерживать продукт в случае изменений, не умеют этого. Далее опишу основные встречаемые проблемы/
Вот буквально недавно ещё 2 "закатных" проекта видел за последние 3 месяца. В 1 MVP. Во 2 "чистая архитектура" + MVP + ещё message bus на все вызовы(методы) бизнес логики... И вот одна из самых криповых и очень распространённых практик во всех подходах разделения кода на M - M остаётся без логики, чисто данные(или почти так). Это слабоумие преследует команды уже 15 лет! Не так давно я думал, что это уже ушло в прошлое, но нет, это всё ещё часто даже у разрабов с опытом в 5 лет встречается, что другого они и не видели.
Вторая проблема - подходы из других областей. Приходит очередной вебщик, CRM-щик и т.п. И тащат свои системы в Unity. Контроллеры на каждый чих? MVC в худшем его извращённом представлении, где M данных, а С логики. Или просто контроллёры всего подряд, что фактически PP. Видел это десятки раз.
Сейчас ещё почти повсеместно использование DI. Но про контейнеры даже не слышали. Как сделать массовое создание объектов. Вместо удобного управления зависимостями выходит god-контекст. Портянки зависимостей на сотни using. И так почти все проекты. Т.е. люди не научились с ООП зависимостями работать, а тут им подогнали крутой инструмент где их вообще вертеть можно как угодно. Вот они и вертят. Пока не встречал ни 1 проект, где с зависимостями хорошо работали в Unity. Часто наоборот, это было ужасно. Чуть в стороне, но не менее часто ломающий логику ООП и производительность - повсеместно используемый UniRx. Каки другие плюшки из других систем, которые влияют на связи между методами и тем более классами.
А, ну и не достаточно просто сказать - мы делаем M***. Так не работает - нужно нормально проводить дизайн фич, проектировать. Это надо в любой парадигме. А ООП, похоже, сильнее чем прочие зависит от этого. Буквально, всё только в это и упирается - не провели дизайн/проектирование классов и зависимостей, то считайте у вас и не ООП. Да, с опытом можно это делать на ходу, но сначала нужно этот опыт получить.
Логика разная, но интерфейсы одинаковые. Каждый в армии может работать по командам армии, а не, например, игрока. Но при этом действовать как отдельная единица по тем же командам, которые даёт 1 игрок. То же со сражением.
Не понятно при чём тут композиция вообще. Новую логику так или иначе придётся отдельно реализовать, она само по себе не появится.
Ни разу. Это чушь про мотивацию. Вообще, это крайне плохой подход. Отсев по "мотивации", которая не статична во времени, является просто очередным барьером. На деле же говорит только о том, кто может выделить достаточно ресурсов в жесткой форме требований. А люди не просто разные, а ещё и в разных условиях и по разному способны на адаптацию. В то же время какой-то чел забрасывает эти ваши ВУЗ-ы и создаёт теорию эволюции. Да, он проучился в колледже, но так же не особо занимаясь. Однако доступ к знаниям имел. Без этого доступа не было бы знаний. Но с жесткой структурой и без "мотивации" он бы там вообще не учился и теорию скорее всего не создал.
А всё потому, как человек несколько сложнее кем-то выдуманных представлений и о мотивации, и об эффективности. И на деле таких случаев очень много. А такой подход, фактически является, не более, чем инструментом классового расслоения. Большинство молодых людей не знают хотят ли работать по профе, в которой учатся, что в ЮК, что у нас, что в других странах
Никто не мешает повысить ЗП джуну и он не уйдёт, либо вернётся через некоторое время. Часть времени будет уходить на джуна, а джун будет делать задачи, которые иначе бы делал, скажем, мидл, и пусть задача более проста, но после обучения во 2 раз джун будет делать её ни чуть не хуже мидла за ЗП в 2-3 раза меньше. В т.ч. очень простые задачи, которые мидлу надоели и он не хочет ими заниматься. А если таких задач много, и скидываются они на перспективного мидла, то такой мидл уходит. Сколько стоит искать такого мидла?
Единственная причина не брать +- подходящих спецов на задачи уровня джуна именно джуна(и далее по такой же схеме), а брать только сеньоров - невозможность нормального использования в команде(1.5 землекопа в команде) или слабое руководство, что не может наладить процессы и компенсирует это высоким уровнем спецов на любой чих
Тут вопрос чем именно ломается. Изменение в логических операторах или последовательностях всё же много чаще, чем изменение принципов. А это как раз ломает уже построенную архитектуру ECS. И такое изменение может потребовать проработки всей группы из-за высокой связности. Тут уже писал, имхо, ECS хорош как раз там, где такой сложной логики нет, а классификация вообще не требует последовательного выполнения. Но не редко сложная логика в таком виде приводит к дополнительным вычислениям и данным, дабы реализовать те же условия логики как часть данных.
Так, многие и про *-варианты не слышали) Тут знать терминологию не надо, чтобы понять суть. А она вообще в другом
Любая новая когнитивная деятельность поначалу неудобна) ECS так же поначалу часто неудобен почти для всех, не важно что там с ООП. Да даже само по себе программирование то ещё неудобство)
В таких вещах хорошо смотреть как удобно это читается, чинится, изменяется. И вот в первых двух неудобств у ООП нет вовсе. Изменения посложнее, но если не требуют перепроектирования, то так же крайне просты. И, что не маловажно, изменения совпадают с дизайном(ТЗ) большинства людей.
Это не пример выжившего лётчика, а как раз вполне обыденный. Если убрать шелуху, которую присваивают постфактум людям, то можно заметить, что как раз выбивающиеся из правил двигают что-то в мире, в т.ч. науку. А из "отличников" % таких людей ни чуть не отличается, хотя у них часто куда лучше среднего стартовые возможности и доступ к лучшему образованию.
Там выше человек писал, о том как было бы замечательно провести сегрегацию людей по школьным знаниям. Принудительно
Когда у тебя объекты из РПГ, где каждый имеет свою особую логику, то легко увидеть, что SIMD работает на 1-2 объектах, а дополнительные цепочки вызовов функций на порядок больше, потому как создаётся огромное кол-во классов с ~1 логическим действием.
Про критику не соглашусь. В некоторых случаях порядок не важен и так можно выстраивать архитектуру - это лучший способ. Но так не всегда получается, и тогда нужно иметь чёткий порядок. А если не получается в условиях типа case в ООП, то нужно вводить дополнительные переменные и делать лишний прогон.
Да и в целом, как задать порядок в сложной логике, которая описывается несколькими документами? Я тут не на столько компетентен, но сейчас подозреваю, что лучше вводить булевы переменные для таких случаев, а не контролировать порядок явно. А это падение производительности, но сильное упрощение проектирования.
О какой эффективности проходов по данным говорить, если контроллер требует действий над 1-10 объектами? Тут не то, что SIMD, тут вообще такое выполнение убивает эффективность использования кеша проца, и особенно предсказаний. А где прям много объектов, ну хотя бы 1к+, выигрыш действительно существенный. Но много ли таких ситуаций? До ECS такое решали просто - массивчик, проход по нему внутри цикла. И тот же SIMD можно обеспечить. Хранить и пользоваться такими данными сложно, но часто это конечная логика для C# кода, так что можно было и без ECS запустить 10к юнитов с анимацией на Unity PC. Схожим образом, например, работают(или работали) партиклы.
Про "гибко и безопасно управлять логикой" вообще мимо. Именно с логикой(условиями), у ECS прям проблемно. Перелопатить кучу данных - это да, легко. А вот управление логикой разбивается на кучу частей, которые могут очень неожиданно отработать. Фрагментация логики приводит к неожиданному поведению систем в целом. Что уж, порой без некоторых новых инструментов отладки это было вообще не реально. Хотя иногда это даже в плюс, но не когда требуется чёткое поведение. И тем более, не когда читаешь код и тебе человеки говорят о баге, а ты ещё и не знаешь с сотню систем которые затрагивают это место.
По мне так ECS хороша для какой-нить RTS в части логики юнитов, рендеринга в целом и им подобных. Т.е. где все действия ограничены и почти не содержат условий в принципе или условия сами проистекают из их особенностей(классификации).
О том и речь - не научились ещё в ООП, а уже используют инструмент, что его ломает
Юзкейсы из чистой архитектуры. DDD про другое, хотя те же юзкейсы можно сказать там есть в Application Layer. Смешивать эти 2 подхода странно.
Но применение в таком виде это уже за гранью обоих этих подходов) В обоих случаях БЛ должна быть в модели, в ЧА собсно модель, а в DDD это разные части доменного слоя, как аналог модели это сущности и их агрегаты
В играх часто выходит очень сложная логика, которая не редко умещается буквально в несколько доменов, а то и в 1. Т.е. DDD там по этой же причине толком не применяется - излишне. Чистая архитектура примерно то же самое, хоть она попроще, поменьше, всё равно слишком избыточна.
Общие подходы с разделением на схожие части и связи в хороших проектах есть всегда и +- соответствуют этим 2, только без бойлерплейта. Тут почаще можно встретить MVC, например, ну или MVVM. Этого разделения + чуть-чуть смысла, и часто хватает за глаза. Основная сложность всё равно остаётся внутри логики
В цикле статей(маг и воин, 5 частей) такое наследование как раз и должно быть. Он в 5 части раскрывает как это сделать без боли, точнее почему это работает и в чём ошибка была. Но примера в коде не даёт
15-20 лет назад про ООП много говорили. И почти никто не умел. Я это понял чутка позже. Сам я писал вначале в процедурном стиле. Первые компроекты вообще целиком процедурками были. Лет 5-15 назад я прям смотрел на проекты и видел Успешные проекты в геймдеве именно в процедурном стиле. Много видел разговоров про ООП и тп., а проект всё те же процедурки, но с финтифлюшками, функциональщиной, реактивщиной и т.п.. Последний такой видел в распространённой мидикорке или казуалке с прокачкой особняка и т.п. До асинков и аналогов ещё часто встречал колбечное программирование - отдельный вид мазохизма, который, к счастью, совсем почти вымер. Это не как ООП в C# с event-based в норме в то время, или промисами java, а часто именно процедурный стиль
Так вот даже тот последний проект в процедурном держал дубли кода, тащил кучу зависимостей, контроллеры пухли очень сильно и разбираться в этом было так сложно, что разрабы тупо забивали на поиск кода(сотни или тысячи строк сильносвязного кода в 1 классе). Логика была размазана в контроллере, из-за чего происходила циклическая правка багов.
Но логика не была размазана между контроллерами, легко было отследить что откуда стартует и что изменяет, и в целом была на месте. Т.е. изначально проект грамотно спроектировали. Только в целом понять как оно работает было почти невозможно, не разбирая код по кирпичику до самого основания.
Потихоньку сконвертили многое в ООП и проблема с пониманием как работает та или иная вещь полностью ушла - это стало легко посмотреть прямо в коде, не спрашивая дизайнеров о том, что делали пару лет назад люди, которых уже давно нет. Зависимостей так же стало в разы меньше.
Многие из процедурного так и "не выросли". Не знаю, может даже большинство. Я на собесах ни разу не встречал вопросов о проектировании, например. Инструменты ООП - этого полно. А вот как их применять - почти и не помню такого. Впрочем, по паттернам так же. Вопросы о паттернах есть, а об их применении, условиях, последствиях - нет. Сами собеседующие часто не особо шарят. И сам когда спрашиваю, да хотя бы об алгоритмах, редко кто может сказать про общие принципы, хотя за плечами бывает явно не плохой бек и не мало проектов.
Про 10 классов - это как раз часто не смогли, кроме некоторых случаев подходов, типа интерфейс как контракт
Флаг именно в таком виде, если он не нужен в ECS, может так же реализовываться в ООП. Конкретно указанный случай скорее некорректен, т.к. его быть в целом не должно.
Ну да, планировать надо. В ECS тоже. Только сам ECS подталкивает к этому. Но есть момент, что когда логика становится сложной, то наборы правил тоже становятся очень сложными. Как и отслеживание логики и последовательности изменения состояния. И часто это много сложнее чем в ООП, потому как логика действия и изменения данных проходят большие цепочки контроллеров. Чуть ошибёшься в очерёдности, не добавишь для её контроля и тп - всё поломается. Кстати, и производительность такого кода много меньше, чем в ООП.
Чистые данные без методов - это не про функциональщину) Там, пусть и условно, всегда есть методы для каждого состояния и они как раз условно содержат состояние, точнее меняют текущее. Но и выполняются они не такими группами и позволяют менять состояние целиком. А так можно и ООП назвать похожим, там тоже есть данные и применяемые к ним методы, прям как в FP, но уже есть "сайдэффекты". Всё таки разница в подходах по сравнению с DOP огромна в обоих случаях, и ещё больше в вариантах для Unity
Штраф будет, т.е. его выпишут без твоего на то желания. Дальше только в суд. А судьям всё равно) По этой статье и до ВС доходили не раз, но туда далеко не все дела желающих попадают на рассмотрение. И судьи, как правило, не смотрят такие дела, просто за глаза вынося решения.
Ни капли не выше, если вы в биологии на школьном уровне разбираетесь и можете хотя бы не много разобраться в ответах. Разницы между случайным врачом и гуглом просто нет при случайном же заболевании, даже если не разбираешься более глубоко. К сожалению, сейчас такова действительность
Врач скорее будет лучше только в некоторых обстоятельствах, например, заболевание типичное для местности или качеств больного, специфично для опыта врача, при ведении больного длительное время, и прочих подобных случаях
Зависит от правил и структуры игры. Выделение памяти для любого мидла в геймдеве решить не проблема. Массивы-списки это ещё не плохо. Сейчас не редко реактивку пихают. Поля ID вообще тут при чём? Обычно это появляется при подключении БД.
Геймдев уровня mov [edx],ebx умер больше 30 лет назад. На уровне движков в случае особых оптимизаций это ещё можно встретить, и то, не мала вероятность что за такой код тебя побьют. И правильно, т.к. компиляторы не плохо работают.
Флаги и проверки посреди, в стиле, а всё ли ок с данными, их надо отсортировать, проверить вообще есть ли подходящие и т.д. - признак плохого проектирования в ООП.
Монструозные циклы не редко то же самое) Но тут не всегда, иногда всё же бывают большие циклы, но скорее там, где надо сложную обработку данных и быстродействие, например, обработку мешей.
А, ну и ECS с функциональщиной ничего общего не имеет. По структуре методов это считай процедурка. Вероятно, тебе проще структурировать информацию в ECS. В таком подходе это структурирование является обязательной частью работы, поэтому её не пропустишь - код вообще не будет правильно работать. В ООП в некотором роде схоже нужно структурировать, но можно забить и писать в процедурки
Что мешает без RX на эвентах то же самое сделать? А чтобы проще была сортировка сделать с аргументом по хешу. И тогда кто угодно сможет подписаться и получать данные. Правда, обработка будет идти параллельно, если подписчика 2. Но там уж можно как угодно вертеть под свои нужды
MVC, MVP, MVVM и все прочие с выделением модели
Не сарказм ли это?
90% связующего кода и 10 логики - это прям эталон того, что делается что-то не так.
И это как раз очень плохой код на больших системах, который ещё и разрастается быстро и бесконтрольно. Как минимум, в нём всегда будет ещё много-много строчек кода условий, которые будут говорить как именно перемножать и надо ли это вообще делать, так же там появятся досрочные выходы, и выходы посреди метода(break посреди циклов и return посреди и в начале метода). Это всё как раз ошибки проектирования в OOP. В норме (почти) не должно быть выходов посреди методов, лишних связей, как и управляющих объектов так же минимально - логика внутри объекта.
Это ни разу не ООП, это как раз вариация ПП.
Я уже десятки команд встречал и соглашусь насчёт ECS полностью. Простые действия в несколько строк в COP(OOP) делаются через создание нескольких файлов. ECS был бы удобен именно как внутренний слой в циклах обработки - почему так не сделали с теми же MB совсем не понимаю.
В большинстве случаев, когда говорят о том, что в ООП плохо, не получается и т.д, и тп = команды просто не могут в ООП. Не могут заранее спроектировать и поддерживать продукт в случае изменений, не умеют этого. Далее опишу основные встречаемые проблемы/
Вот буквально недавно ещё 2 "закатных" проекта видел за последние 3 месяца. В 1 MVP. Во 2 "чистая архитектура" + MVP + ещё message bus на все вызовы(методы) бизнес логики... И вот одна из самых криповых и очень распространённых практик во всех подходах разделения кода на M - M остаётся без логики, чисто данные(или почти так). Это слабоумие преследует команды уже 15 лет! Не так давно я думал, что это уже ушло в прошлое, но нет, это всё ещё часто даже у разрабов с опытом в 5 лет встречается, что другого они и не видели.
Вторая проблема - подходы из других областей. Приходит очередной вебщик, CRM-щик и т.п. И тащат свои системы в Unity. Контроллеры на каждый чих? MVC в худшем его извращённом представлении, где M данных, а С логики. Или просто контроллёры всего подряд, что фактически PP. Видел это десятки раз.
Сейчас ещё почти повсеместно использование DI. Но про контейнеры даже не слышали. Как сделать массовое создание объектов. Вместо удобного управления зависимостями выходит god-контекст. Портянки зависимостей на сотни using. И так почти все проекты. Т.е. люди не научились с ООП зависимостями работать, а тут им подогнали крутой инструмент где их вообще вертеть можно как угодно. Вот они и вертят. Пока не встречал ни 1 проект, где с зависимостями хорошо работали в Unity. Часто наоборот, это было ужасно.
Чуть в стороне, но не менее часто ломающий логику ООП и производительность - повсеместно используемый UniRx. Каки другие плюшки из других систем, которые влияют на связи между методами и тем более классами.
А, ну и не достаточно просто сказать - мы делаем M***. Так не работает - нужно нормально проводить дизайн фич, проектировать. Это надо в любой парадигме. А ООП, похоже, сильнее чем прочие зависит от этого. Буквально, всё только в это и упирается - не провели дизайн/проектирование классов и зависимостей, то считайте у вас и не ООП. Да, с опытом можно это делать на ходу, но сначала нужно этот опыт получить.
Логика разная, но интерфейсы одинаковые. Каждый в армии может работать по командам армии, а не, например, игрока. Но при этом действовать как отдельная единица по тем же командам, которые даёт 1 игрок. То же со сражением.
Не понятно при чём тут композиция вообще. Новую логику так или иначе придётся отдельно реализовать, она само по себе не появится.
Ни разу. Это чушь про мотивацию. Вообще, это крайне плохой подход. Отсев по "мотивации", которая не статична во времени, является просто очередным барьером. На деле же говорит только о том, кто может выделить достаточно ресурсов в жесткой форме требований. А люди не просто разные, а ещё и в разных условиях и по разному способны на адаптацию. В то же время какой-то чел забрасывает эти ваши ВУЗ-ы и создаёт теорию эволюции. Да, он проучился в колледже, но так же не особо занимаясь. Однако доступ к знаниям имел. Без этого доступа не было бы знаний. Но с жесткой структурой и без "мотивации" он бы там вообще не учился и теорию скорее всего не создал.
А всё потому, как человек несколько сложнее кем-то выдуманных представлений и о мотивации, и об эффективности. И на деле таких случаев очень много. А такой подход, фактически является, не более, чем инструментом классового расслоения. Большинство молодых людей не знают хотят ли работать по профе, в которой учатся, что в ЮК, что у нас, что в других странах
Никто не мешает повысить ЗП джуну и он не уйдёт, либо вернётся через некоторое время. Часть времени будет уходить на джуна, а джун будет делать задачи, которые иначе бы делал, скажем, мидл, и пусть задача более проста, но после обучения во 2 раз джун будет делать её ни чуть не хуже мидла за ЗП в 2-3 раза меньше. В т.ч. очень простые задачи, которые мидлу надоели и он не хочет ими заниматься. А если таких задач много, и скидываются они на перспективного мидла, то такой мидл уходит. Сколько стоит искать такого мидла?
Единственная причина не брать +- подходящих спецов на задачи уровня джуна именно джуна(и далее по такой же схеме), а брать только сеньоров - невозможность нормального использования в команде(1.5 землекопа в команде) или слабое руководство, что не может наладить процессы и компенсирует это высоким уровнем спецов на любой чих