Паттерн стратегия в Unity
Большинство задач уже решались когда-то разработчиками, поэтому часто разработка сводится к использованию уже существующих паттернов программирования. В этой статье мы разберем один из них – стратегия. Итак, допустим у вас есть класс суперкласс Citizen, который на основании enum меняет свое взаимодействие с игроком.
Такой код часто перерастает в спагетти и его сложно поддерживать и развивать. Мериться с этим мы не будем и используем один из принципов ООП – наследование, чтобы можно было добавлять различные типы жителей.
Метод общения с игроком переопределен. Кто-то просто общается с жителем, кто-то запускает квест, а есть неговорящие NPC. Но тут заказчик говорит, что необходимо будет добавить функционал обмена с жителями. Мы решаем эту проблему добавлением в родительский класс метода торговли, но тут получается, что мы можем торговать даже с теми жителями, с которыми не можем общаться. Попробуем сделать метод virtual и переопределить, где необходимо. Заказчик доволен, но как только геймдизайнер добавляет новых жителей в город становится неудобно это все поддерживать. Например часовой, которому нужно переопределить метод общения, и торговать с нами он не может. После небольшого брейншторма принимается решение использовать интерфейсы.
Определяем интерфейсы Itradeble Imoveable ISpeakeable, в итоге получается более гибкая система. Каждый житель будет наследовать лишь те интерфейсы, которые необходимо. Но потом становится задача, как бороться с большим количеством одинакового кода, ведь много жителей будут иметь похожее поведение, любая попытка что-то изменить, повлечет изменение во всех частях кода, повторное изменение.
Далее принимается решение выделить части кода, которые изменяются часто, и которые более-менее константы. Логически понятно, что система квестов точно будет изменяться часто, также как и паттерн движения по городу. На это уже намекает создание интерфейсов. Для этого необходимо отделить системы от игрока и сделать их самостоятельными. Также у нас появится возможность изменения поведения в реальном времени. Для этого необходимо в суперклассе поля интерфейсы, которые будут отвечать за каждую систему, движения, квестов и т.д. Для каждой системы создавать необходимый класс, реализующий данный интерфейс, в котором будет логика определенной системы. Отсюда вытекает один из принципов программирования – программировать на уровне абстракций, а не реализаций. Таким образом у нас получается система, которая может изменяться со временем и код, который нам несложно дополнять. Если создается необходимость создать какую либо новую систему, то достаточно просто создать необходимый интерфейс.
Помимо большинства очевидных преимуществ, есть и неочевидные недостатки. Во первых увеличивается количество кода и сложность системы. Во-вторых не всегда бывает легко выделить четко какую-либо систему, также сложность выбора стратегии. Но несмотря на все недостатки, это намного лучше, чем огромное количество трудноизменяемого кода.