Архитектурные паттерны для игры

Question

Итак, у меня есть решение, которое содержит несколько крупных проектов, которые я пытаюсь разбить на более мелкие проекты с более изолированными обязанностями. Это игра, но я в основном разработчик LOB, и я думаю, что принципы, вероятно, универсальны, и я думаю, что я мог бы кое-что узнать здесь.

Зависимости в некоторых объектах слишком тесно переплетены, и я надеюсь на некоторую помощь в том, как их распутать. Или, может быть, какой-то шаблон или абстракция, которые могут сделать их более управляемыми.

Ares.Core.World содержит классы, такие как существа, предметы и т. Д. Все они наследуются от сущности, которая знает, в какой ячейке на карте она существует. Это достигается путем удержания ссылки на Ares.Core.UI.MapControls.MapCell ... И вы можете видеть, что провода уже пересекаются.

Ares.Core.UI.MapControls содержит Map и MapCell, каждый из которых содержит списки существ и предметов, которые они содержат. MapCell также наследует от Ares.Core.World.Entity, поскольку это очень элегантно решило несколько ранних проблем - например, у всех сущностей есть инвентарь.

Я хотел бы найти способ разделить пользовательский интерфейс и мир на отдельные проекты ( Ares.World и Ares.UI ), поскольку пользовательский интерфейс и всеобъемлющий мир, вероятно, должны быть разделены проблемы. Но, как вы можете видеть, в нынешних двух проектах необходимо ссылаться друг на друга, и циклические ссылки не допускаются.

Мне интересно, есть ли какие-нибудь архитектурные паттерны, которые могли бы помочь в этой ситуации. Спасибо!

Answer 1

Итак, классы вашего Мира - Существа, Предметы и т. Д. - им всем нужно что-то от MapCell.

Можете ли вы разумно создать интерфейс (или несколько), представляющий то, что нужно Мировым Сущностям? Так что сущностям нужна только реализация этого интерфейса?

Это был бы первый шаг к их разделению. Возможно, очевидно, что ни одна из сигнатур методов или свойств этого интерфейса не может включать классы из проекта пользовательского интерфейса. Он должен быть определен со стандартными типами или пользовательскими типами в библиотеке, как в World, так и в пользовательском интерфейсе (например, Ares.Core).

Затем в проекте пользовательского интерфейса определите реализации интерфейса (ов), которые инкапсулируют MapCell и предоставляют то, что необходимо для World Entities.

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

Без более подробной информации о ваших конкретных потребностях сложно быть конкретным, но я думаю, что этот подход в целом должен быть работоспособным.

Answer 2

Нет ничего плохого в том, что классы в разных пространствах имен взаимодействуют на тонком уровне.Разделение проблем может быть выполнено на уровне защиты доступа (общедоступный, защищенный, частный и т. Д.).Вы можете разбить ваш проект на подпроекты как логически, так и структурно, применяя любые дополнительные организационные ограничения, которые вы считаете уместными.

Некоторые стратегии могут быть:

• Структурно разделяющая логика, где каждый бункерслучается, что они находятся в их собственных установленных пространствах имен и взаимодействуют только через высокоуровневые интерфейсы.
• Логическое разделение, где сборка (или набор asms) становится логическим проектом, который может охватывать несколько пространств имен.Взаимодействие может осуществляться через интерфейсы, но также через тщательное рассмотрение доступа членов.

Чтобы распутать их, попробуйте посмотреть на проект с разных точек зрения.То, что может выглядеть как полный беспорядок от одного POV, на самом деле может выглядеть элегантно от другого POV.Если вы обнаружите, что на самом деле существует разумная логика, лежащая в основе их структуры классов, возможно, все, что нужно, - это начать разделять части и куски на разные сборки, с небольшими изменениями в пространствах имен.Если вы обнаружите, что это действительно хаос, то ваша работа обрезана для вас: -D

Answer 3

1. Разделяй и властвуй дизайн предлагает разделить пользовательский интерфейс и основной компонент.
2. Ваша игровая логика должна быть частью основного модуля вместо пользовательского интерфейса.
3. Пользовательский интерфейс должен иметь графический интерфейс и интерфейс действий или интерфейс поведения объекта и реализовываться базовым модулем.