Серия «Принципы S.O.L.I.D в Unity»

Принцип подстановки Барбары Лисков в игровом движке Unity

Добро пожаловать на очередной выпуск нашего канала! Сегодня мы подробно разберём один из важнейших принципов ООП — принцип подстановки Барбары Лисков (Liskov Substitution Principle). Выясним, почему он важен и как правильно применять его в играх на платформе Unity.

Что такое принцип подстановки Барбары Лисков?

Принцип подстановки Барбары Лисков гласит: объекты подклассов должны корректно заменять объекты родительского класса без нарушения работоспособности программы. То есть, если у вас есть интерфейс, использующий базовый класс, вы можете спокойно подставлять туда экземпляр производного класса, и всё должно продолжать работать ожидаемым образом.

Почему это важно?

Представьте такую ситуацию: вы создаёте персонажа в игре, наследуя его поведение от абстрактного базового класса. Если вдруг замена экземпляра дочернего класса ведёт к неожиданному поведению или ошибкам, значит, ваше приложение спроектировано неправильно. При работе над проектами в Unity придерживайтесь следующих рекомендаций:

• Используйте полиморфизм: создавайте универсальные методы и свойства, подходящие для разных типов объектов.

• Проверяйте границы поведения: убедитесь, что изменения в потомках соответствуют контрактам базовых классов.

• Тестируйте реализацию: применяя тесты и контрольные проверки, удостоверитесь, что поведение ваших объектов соответствует заявленным требованиям.

Следование принципу подстановки Барбары Лисков делает ваши проекты гибкими, расширяемыми и устойчивыми к изменениям. Всегда помните о нём, разрабатывая свою следующую игру на Unity! Спасибо за просмотр! Оставайтесь с нами и подписывайтесь на канал!

Теги: #unitydev #gamedev #разработкаигр #unitycommunity #игрынасоздание #создайигру #учисьделатьигры #геймдев #индиразработчики #programming #design #graphics #gameart #unitylearning #beginnerswelcome #unitygames #unityengine #vkgamedev #русскоязычныеразработчики

Рассмотрим пример игры на Unity, где мы хотим создать систему управления персонажем игрока. Предположим, персонаж может двигаться, атаковать врагов и собирать предметы. Как применить SRP?

Неправильный подход

Один большой скрипт PlayerController, содержащий весь функционал персонажа:

Этот подход нарушает SRP, потому что класс несет ответственность за движение, атаку и сбор предметов одновременно.

Правильный подход

Разделяем функциональность на отдельные классы:

Скрипт MovementController

Отвечает исключительно за перемещение персонажа:

Скрипт AttackController

Обрабатывает атаки персонажа:

Скрипт ItemCollector

Занимается взаимодействием с предметами:

Теперь каждый класс имеет свою четкую зону ответственности, и изменения в одном классе не влияют на остальные.

Преимущества разделения обязанностей

Легкость поддержки: проще находить и исправлять ошибки, поскольку каждая задача отделена друг от друга. Простота расширения: добавить новую возможность становится легче, так как достаточно внести изменения только в соответствующий класс. Улучшение тестируемости: небольшие классы легче покрыть юнит-тестами. Повышенная читаемость: разработчики быстрее понимают назначение каждого компонента системы.

Заключение

Применение принципа Single Responsibility Principle позволяет сделать ваш игровой проект на Unity более устойчивым к изменениям, легким в поддержке и понятным другим разработчикам. Следуя этому принципу, вы создаете основу для качественной архитектуры проекта, облегчающей разработку сложных игровых механик и интерфейсов.

Теги: #unitydev #gamedev #разработкаигр #unitycommunity #игрынасоздание #создайигру #учисьделатьигры #геймдев #индиразработчики #programming #design #graphics #gameart #unitylearning #beginnerswelcome #unitygames #unityengine #vkgamedev #русскоязычныеразработчики

Реализация принципа Open/Closed в Unity

Прежде чем рассмотреть, реализацию принципа в Юнити, предлагаю посмотреть на то, как этот принцип нарушается. Часто разработчики нарушают принцип Open/Closed, добавляя новый функционал непосредственно в существующие классы. Например, рассмотрим сценарий игры, где игрок должен управлять своим кораблем. Изначально логика управления реализована следующим образом:

Теперь представьте ситуацию, когда нам нужно добавить некоторый дополнительный функционал, который должен работать по другому принципу. Например стрельбу.

Мы бы написали что-то вроде этого, и после добавили бы переменную Weapons в класс Player и вызвали бы в методе Update метод стрелять.

И вот как бы у вас все работает, но тут наступает время создать противника. И вы пишите что-то вроде Enemy для него отдельное управления. В общем и целом я не говорю что это плохой подход, и ему есть место быть, но я бы поступил иначе.

СОЗДАНИЕ ЕДИНОГО КЛАССА ДЛЯ ВСЕХ СУЩНОСТЕЙ

В первую очередь, я бы избавился от конкретных реализаций сущностей. Что я имею ввиду.

Я бы создал класс, который мог содержать в себе поведенческие типы и обрабатывался через интерфейс. Выгладил бы он так:

На смену переменной типа Movement, пришла переменная с типом IBehaviour. IBehaviour – это интерфейс который имеет всего лишь один метод OnUpdate(). Теперь наше общение с нашим классом поведенческого типа стала универсальным, так как теперь мы принимаем в качестве переменной не конкретный поведенческий класс, а интерфейс. Такой подход хорош для того что бы начать собирать наш класс контейнер. Однако, нужно помнить, что поведенческих классов может быть огромное количество и для каждого пришлось бы реализовывать свою переменную. Выгладило бы, это примерно вот так:

Но мы с тобой не дураки, и понимаем.. Что нам нужно реализовать массив типа List который будет содержать в себе все поведенческие типы которые нужны для работы той или иной сущности. Модифицируем наш класс Actor под наши задачи, а задача у нас простая. Реализовать контейнер поведений которые обрабатываются все в одном месте.

Теперь давайте посмотрим, на реализацию классов EnemyMovement и PlayerMovement.

Отлично, и теперь по такому же принципу мы можем изменить наш класс Weapons.

Итог

За счет того, что мы сделали методы OnEnable и OnDisable, у нас с вами появилась гибкость.

• В методе OnEnable - мы спокойно получаем доступ к нашему Actor и добавляем себя в массив.

• В методе OnDisable- мы спокойно получаем доступ к нашему Actor и убираем себя в массив.

В данном случае мы можем тестировать разные механики на лету, не боясь что код который у нас отвечает за персонажа или какаю-то другую сущность сломается. И ко всему к этому у нас появляется возможность собирать все как конструктор. В следующей статье, я постараюсь максимально разобрать принцип LSP операясь на уже существующий код.

Теги: #unitydev #gamedev #разработкаигр #unitycommunity #игрынасоздание #создайигру #учисьделатьигры #геймдев #индиразработчики #programming #design #graphics #gameart #unitylearning #beginnerswelcome #unitygames #unityengine #vkgamedev #русскоязычныеразработчики

#OpenClosedPrinciple #SOLID #SoftwareDesign #ProgrammingConcepts #Encapsulation #Extensibility #CodeMaintenance #Refactoring #OOP #CleanCode