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

Question

Так что этот вопрос - вот что следует отсюда (how to deal with multiple event args). Этот вопрос заставил меня подумать об этом, но он достаточно разный, чтобы оправдать собственную нить.

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

EDIT

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

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

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

alt text http://lh3.ggpht.com/_eoaz2oX5m6U/SypiyjHGQoI/AAAAAAAAAUo/2geWlqNHqbs/structure.jpg

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

alt text http://yuml.me/3279d2ac

Click here to link to full page for UML, makes it a little larger and hopefully easier to read

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

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

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

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

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

То, что я хотел бы знать:

1) Является ли это разумный подход?

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

3) Неужели я зашел слишком далеко с разделением проблем?

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

EDIT

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

Благодарим вас за ваши мысли и отзывы.

Answer 1

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

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

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

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

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

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

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

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

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

Answer 2

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

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