Я думал об этом в течение нескольких дней, и я все еще не уверен, что делать. Я пытаюсь реорганизовать боевую систему в PHP (... извините.) Вот что существует до сих пор:
- Есть два (пока) типа сущностей, которые могут участвовать в бою. Давайте просто назовем их игроками и неигровыми персонажами. Их данные уже написаны довольно хорошо.
- Когда они участвуют в бою, эти объекты обертываются другим объектом в БД
Combatant
, который называется a , который дает им информацию о конкретном бою. Они могут участвовать в нескольких боях одновременно. - Я пытаюсь написать логику для боя, вводя в него бойцов.
- Я хочу быть в состоянии высмеять все для тестирования.
Чтобы разделить логику и данные, я хочу иметь два интерфейса / базовых класса, один из которых ICombatantData
является другим ICombatantLogic
. Два реализатора данных будут один для реальных объектов, хранящихся в базе данных, а другой для моих фиктивных объектов.
Сейчас я сталкиваюсь с неопределенностью при разработке логической стороны вещей. У меня может быть один исполнитель для каждого из игроков и NPC, но у меня есть проблема. Комбатант должен иметь возможность вернуть сущность, которую он оборачивает. Должен ли этот метод получения быть частью логики или данных? Я твердо считаю , что это должно быть в данных, так как логика часть используется для выполнения боевых и не будет доступна , если кто - то просто смотрит информацию о предстоящей борьбе. Но классы данных только отделяют макет от БД, а не игрока от NPC. Если я попытаюсь иметь два дочерних класса для реализации данных БД, по одному для каждого типа сущности, то как мне это спроектировать, сохраняя при этом мои макеты в цикле? Нужен ли какой-то третий интерфейс, подобный тому, IEntityProvider
который я внедряю в классы данных?
Кроме того, с некоторыми из идей, которые я рассматривал, я чувствую, что мне придется поставить чеки, чтобы убедиться, что вы не несоответствуете, например, сделать логику для NPC случайно обернуть данные для игрока. Имеет ли это хоть какой-то смысл? Это ситуация, которая была бы даже возможна, если архитектура правильна, или правильный дизайн полностью запрещает это, так что мне не нужно проверять это?
Если бы кто-то мог помочь мне просто составить схему класса или что-то для этого, это бы мне очень помогло. Спасибо.
редактировать
Также полезно отметить, что класс фиктивных данных на самом деле не нуждается в Entity
, так как вместо этого я просто укажу все параметры, такие как боевая статистика. Так что, возможно, это повлияет на правильный дизайн.
Combatant.entity
что не используется во время боя и поэтому не должно существовать. Возможно, вам нужен другой класс, например,EntityVsEntityCombat
который оборачивает боевую логику, содержитEntity <--> Combatant
отображения и обновленияEntity
состояний после окончания боя? Может быть, немного больше информации о вашей текущей архитектуре может помочь.