SRP диктует, что класс должен иметь только одну ответственность. Это часто противоречит взаимосвязанной природе разработки игр.
Рассмотрим персонажа ролевой игры (RPG). Он может обладать такими возможностями, как перемещение, атака, взаимодействие с окружающей средой и отображение анимации. Придерживаясь SRP, можно было бы разделить эти функциональные возможности на отдельные классы, такие как CharacterMovement, CharacterCombat, CharacterInteraction и CharacterAnimation. Такой подход, хотя и является чистым с точки зрения SRP, может привести к обилию классов. Поведение персонажа становится разбросанным по всей кодовой базе, что усложняет понимание, поддержку и отладку.
Принцип открытости-закрытости (OCP)
Согласно OCP, программные объекты должны быть открыты для расширения, но закрыты для модификации. Этот принцип оказывается сложным в контексте разработки игр - области, характеризующейся итеративной и динамичной природой.
Например, оружие в игре-шутере от первого лица может изначально включать в себя базовый пистолет. По результатам игрового тестирования разработчикам может понадобиться добавить к оружию новые функции, например, лазерный прицел или увеличенный магазин. Такие модификации часто требуют внесения изменений в существующий код, что противоречит принципу OCP.
Принцип замещения Лискова (LSP)
LSP - это еще один принцип, который часто противоречит реалиям разработки игр. Этот принцип утверждает, что объекты суперкласса должны иметь возможность быть заменены объектами подкласса без ущерба для корректности программы.
В игре, однако, это часто не так. Например, рассмотрим врага-босса, который является подклассом класса общего врага. Враг-босс может обладать уникальными способностями или поведением, не присущими общим врагам. Функция, разработанная для работы с общими врагами, может работать некорректно при замене врага-босса, что нарушает LSP.
Принцип разделения интерфейсов (ISP)
ISP утверждает, что множество интерфейсов, специфичных для клиента, лучше, чем один интерфейс общего назначения. Однако этот принцип может привести к фрагментации и ненужной сложности при разработке игр.
Игровой объект, например, персонаж игрока, может взаимодействовать с предметами, врагами, игровым окружением и пользовательским интерфейсом игры. Если для каждого типа взаимодействия требуется свой интерфейс, как предполагает ISP, код может быстро стать разрозненным, запутанным и сложным в управлении.
SRP вообще не про "класс должен иметь только одну ответственность". Он про то, что ради изменения одной функциональности не надо изменять более одного места в коде. То есть, не надо лазить по куче связанных классов в разных файлах для изменения одного аспекта.
LSP (он имени Барбары Лисков, а не Лискова) - он в первую очередь про соблюдение предусловий и постусловий.
Пример с боссом не в ту степь, но очевидно, что иерархия классов тут некорректная. Должно быть не Враг -> РядовойВраг -> Босс, а Враг -> РядовойВраг и Враг -> Босс.
ISP про то, что не должно быть огромного интерфейса IPlayer, который может всё, с единственной реализацией в классе Player. Должны быть мелкие интерфейсы навроде ICanMove, ICanInteract и так далее.
ISP про то, что не должно быть огромного интерфейса IPlayer, который может всёМожно сделать фасад который буквально "может всё", внутри это будут те-же мелкие интерфейсы.
для в LSP я обосрался хорошо что мне скинули статью
Статья сама себе противоречит.
Там где единственная ответственность куча классов (CharacterMovement, CharacterCombat, CharacterInteraction и CharacterAnimation) это безусловно каша и плохо, а там где компоненты та же куча тех же классов только сбоку (MoveComponent, JumpComponent и CollisionComponent, и это только замена CharacterMovement) это уже благо и хорошо.
Классические ООП подходы хорошо работают и в играх, если применять их с умом, а не пытаться пихать везде бездумно. Впрочем с умом их нужно применять и в обычном программировании.
Возможно ты не правильно понял, потому что в случаее единственной отвественности для каждого моба мы будем создавать GoblinMovement, GoblinCombat,GoblinInteraction ,GoblinAnimation
TrollMovement, TrollCombat, TrollInteraction , TrollAnimation
и т.д.
В случае компонентов 1 компонет MoveComponent используется для всех противников и персонажей.
Очень сомнительная статья.
Попытка переосмыслить SOLID, когда его не понимаешь невозможно.
К тому же, попытка сравнивать разные сущности (SOLID, ECS, Data Driven Design, Design Patterns), априори глупая. Можно сравнивать сущности в рамках одной категории, а они изначально находятся на разных уровнях.
Изучите глубже темы, SOLID (примеры использования в геймдеве/вне геймдева), разберитесь, что такое парадигмы, принципы на более общем уровне, подходы проектирования.
Складывается ощущение, что статья была сделана ради того, чтобы сделать статью, а не сделать полезный контент/рассуждение.
p.s, на хабре за такую статью, вас бы утопили в минусах