Делаю игру (пошаговая стратегия, по типу
этой), по возможности пытаюсь применить новые знания в области ООП и паттернов, когда это помогает решить задачу наиболее просто и эффективно. Но так как я не так давно обратил внимание на программирование на уровне интерфейсов, принципы абстракции и полиморфизма, и это, по сути, моя проба пера, возникает довольно много проблем, которые я решить не могу. Помучавшись над ними, я решил спросить здесь. Возможно, будет немного скомканно, но это как раз из-за того, что я запутался.
1. Есть группа объектов. Она обширная (насчитывает более 200 элементов в планах и будет дополняться новыми). Каждый объект имеет
одинаковый набор
однотипных методов, отличающихся только реализацией. Стоит ли засорять приложение сотнями классов: по одному на каждый подобный объект или можно решить задачу более мирным путем?
Речь идет про способности героев. Они представлены классом Ability, имеют свойства типа перезарядки (и в этом не отличаются), а также должны каким бы то ни было способом вызываться (т. е. применяться в игре). Проблема в том, что способность может делать кучу ништяков - от банального нанесения урона до наложения и диспелла баффов. Разные спсобности - разные наборы действий.
И вот что меня до конца вводит в ступор - так это то, что многие значения, играющие роль в использовании способности, должны еще и обрабатываться. Например, если способность наносит урон, то для него надо будет еще посчитать крит и добавить бонус к урону от надетых предметов на урон (они могут быть не на урон или даже отсутствовать). И при этом, мы не знаем подробности внутренней реализации применения способности!
Собственно, идея про сотни классов была вызвана книгой про паттерны, где во многих примерах в аналогичных ситуациях создавали по классу на объект, например, в главе про Фабричный метод на каждое сочетание типа пиццы и ее стиля было создано по классу. По мне так, это решение не очень, но идея была и я ее изложил. Проблему засоренности можно в крайнем случае решить переносом всех классов способностей в отдельный подпакет, но что начнется, когда в очередном патче надо будет изменить урон и длительность эффекта в, скажем, 10 способностях, образовывавших имбалансное комбо! Рыться во всех 10 классах?
2. Каждого персонажа (npc и игрока, они ведь сходны) представлял класс Unit. Согласно принципу одной обязанности я даже поделил Unit на BattleUnit и RoamingUnit - персонаж в бою (с такими показателями как хп и мана, способный получать урон, тратить ману,..., с постоянными характеристиками) и персонаж после боя (можно менять экипировку, качать характеристики и прочее). Второй класс доступен только для игрового персонажа, на основе его собирается соответствующий BattleUnit. NPC'шные же BattleUnit'ы имеют набор характеристик и способностей и логику, соответствующий их уникальному id.
Имеет ли смысл использовать паттерн Строитель для этой задачи, чтобы собирать npc "по частям"? Как тогда сосредоточить декларацию всех свойств всех юнитов в одном месте? Нужно легко добавлять новых юнитов по ходу разработки.
Стоит ли также применить Строитель для сборки игрового персонажа - ведь на нее влияют характеристики, например, количество здоровья зависит от очков живучести?
3. В режиме просмотра инвентаря и характеристик отображается внешний вид игрока, его инвентарь, экипировка, атрибуты. В нем же их и надо менять. Хорошо ли здесь зайдет паттерн MVC? Модель - RoamingUnit, представление, соответственно, экран, ну и контроллер прикрутить для слабой связности. Если да, то как хранить в контроллере
ссылку на объект RoamingUnit, а не сам объект?
Пока что все. Вопросов, конечно, больше, но их я буду задавать как-нибудь позже. Простите что так много написал, сложно структурировать информацию, в которой сам не до конца разбираешься.