вопрос дизайна / структуры приложения и разделения интересов

Question

Итак, этот вопрос является своего рода продолжением ( как обращаться с несколькими аргументами событий ). Этот вопрос заставил меня задуматься над этим, но он достаточно отличается, чтобы оправдать свою нить.

Я создаю игру (для развлечения и в целях обучения) и хотел бы знать, использую ли я хорошие стандарты для дизайна или нет. Я думаю, что мог бы пойти на ОТТ по разделению интересов, или просто все неправильно понял, но я надеюсь, что это не так. У меня нет проблем переписать его, так как я хочу изучить «лучшие практики» и их практическое применение.

EDIT

Позвольте мне объяснить немного больше об игре. Она основана на игре Jawbreaker, которую можно найти на многих мобильных телефонах ( быстрое демо здесь можно найти ). Цель состоит в том, чтобы выбрать шары, которые находятся в группах, чтобы вывести их из игры и набрать как можно больше очков.

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

Итак, вот структура объектов, которые я создал, в верхней строке показаны библиотеки DLL с их объектами, во второй строке - ссылки на эти объекты:

_{(источник: ggpht.com )}

Вот моя попытка сделать UML:

альтернативный текст http://yuml.me/3279d2ac

Нажмите здесь, чтобы перейти на полную страницу для UML, она немного больше и, надеюсь, легче читать

Библиотека объектов содержит основные объекты, используемые в игре, шары и доску. Они не содержат никакой логики о том, как они действуют / реагируют на ситуации (мяч реализует методы CompareTo и Equals). Может быть X количество реализаций IBall (и то же самое для IBoard, хотя я не думаю, что их будет много).

InstanceManager DLL используется в качестве способа создания объектов, но не уверен, что это на 100% необходимо, чтобы это могло быть в DLL объектов. Фабрики - это статические классы, которые имеют различные перегруженные методы для создания объектов IBall. BallFactory может принимать перечисление BallType, объект Drawing.Color и т. Д. BoardFactory очень похожа. Jawbreaker - это одноэлементный объект, который имеет дело с такими вещами, как удержание случайного объекта, так как он используется очень регулярно, а также с некоторыми данными GameConfiguration (не очень актуальными для этой темы).

Engine DLL - это то место, где происходит большая часть работы. LogicFactories принимает объекты BallType и BoardType для создания соответствующих логических объектов. Логические объекты используются для управления работой объектов IBall и IBoard. BallLogic сообщает мячу, что он может сделать, когда начнутся его события. Например, когда выбран мяч, в логике шара вызывается метод, говорящий о том, что был выбран шар X на доске Y. Мяч может делать то, что должен / мог сделать его тип. BoardLogic очень похож и имеет дело с тем, как действует доска.

Объект Engine - это еще один синглтон, и именно так графический интерфейс взаимодействует со всей игрой. Графический интерфейс не будет создавать экземпляры других объектов напрямую.

Итак, для подведения итогов классы IBall и IBoard содержат только данные о них, классы логики имеют дело со всеми функциями.

Я бы хотел знать:

1) Это разумный подход?

2) Должна ли (вообще) логика быть отделена от объектов / данных?

3) Я зашел слишком далеко с разделением интересов?

4) Любые другие комментарии о дизайне / структуре

EDIT

ThПричина, по которой я использовал пару синглетонов, отчасти из-за простоты доступа к данным в одном месте без постоянного удержания объектов, а также просто потому, что это одиночная игра, и она не будет масштабироваться ни до высокого уровня, ни на нескольких машинах. , Я понимаю, что они не велики, и это не то, чем я регулярно пользуюсь, но ценю комментарии.

Спасибо за ваши мысли и отзывы.

Answer 1

Ваша разбивка выглядит так, как будто идет в правильном направлении. Однако я не уверен, что вы пытаетесь отделить данные из презентации от логики. Взгляните на MVC, наблюдателя и шаблоны стратегий.

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

Answer 2

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

Старайтесь как можно больше избегать синглетонов. Да, я знаю, что книга GoF перечисляет это, и я знаю, что это обычная модель, но по моему опыту она становится анти-шаблонной.

Вы упоминаете, что IBall и IBoard не имеют никакой логики о том, как они взаимодействуют. Означает ли это, что у них нет никаких методов? Являются ли их методы просто геттерами и сеттерами для их личных данных? Если IBall и IBoard являются просто структурами (или их эквивалентами), то они не должны быть интерфейсами. Не могли бы вы конкретизировать свое описание, чтобы рассказать о видах сообщений, которые вы можете отправлять на IBall и на IBoard?

2) Должна ли (вообще) логика быть отделена от объектов / данных?

Иногда. Если у вас есть простые старые данные, то хорошо бы отделить логику от простых данных. Конечно, тогда вы больше не выполняете ООП - вы пишете процедурный код. Я думаю, что вы боретесь с желанием не кодировать любое поведение в Ball. Возможно, какая-то другая организация должна нести ответственность за принятие решения о взаимодействии мячей, но у вас все еще есть место, чтобы Болл мог принять участие в решении. Это где шаблон стратегии (среди других шаблонов) вступит в игру. Подумайте о том, как все работает в реальном мире - как физический шар и физическая доска координируют свои взаимодействия? Если бы они говорили друг с другом, что бы они сказали? Посмотрите, сможете ли вы реализовать это в своем коде.

Наконец, несколько слов о дизайне. Я думаю, это хорошо, чтобы хотеть "получить дизайн правильно". С другой стороны, это путь к становлению астронавтом архитектуры . Подумайте, какие у вас проблемы с базой кода.

• Трудно ли провести рефакторинг?
• Сложно ли добавлять новые типы вещей?
• Слишком много "зашито"?

Дизайн не существует в вакууме - он информирован о текущем состоянии мира. Достаточно взглянуть на сумасшедший концепт-арт сотового телефона, который придумывают люди, и вы увидите хорошие примеры плохого дизайна. Сотовые телефоны ограничены современной технологией, а дизайны, которые игнорируют ограничения реального мира, являются не более чем мечтами. То же самое относится и к программному обеспечению. Обратите внимание на то, что код говорит вам, что нужно, и у вас все будет хорошо.

Чем больше программного обеспечения вы пишете (и заканчиваете), тем больше у вас опыта, и тем лучше будет ваше чувство эстетики. Не позволяйте страху «делать это неправильно» помешать вам закончить работу над программным обеспечением. Продолжайте, заставьте это работать, а затем посмотрите, что вы узнали из этого процесса.