Может ли быть полезным включить графические возможности в классы моделей?

Question

Полезно ли в ОО-дизайне включать возможности рисования в классы моделей в противном случае?

Чтобы привести пример для университетского проекта, мне нужно разработать реализацию настольной игры «билет на поездку».Там у меня есть класс Card, который называется AbstractCard, для представления карты в игре, подклассами которой являются TrainCard и DestinationCard.Класс AbstractCard будет выглядеть следующим образом:

-------------------------------
|      AbstractCard            |
-------------------------------
|                              |
--------------------------------
|drawFront(Graphics2D:g2):void |
|drawBack(Graphics2D:g2):void  |
--------------------------------

Подклассы добавляют дополнительные данные и методы.

Answer 1

В общем:

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

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

Answer 2

Не существует жесткого и быстрого правила, согласно которому вы ДОЛЖНЫ отделить бизнес-логику от пользовательского интерфейса.

Задайте себе эти вопросы:

• Какова вероятность того, что проектируемый вами класс будет изменен в будущем?
• Будут ли добавлены другие пользовательские интерфейсы (представления) в будущем (например, доступ к бизнес-логике через веб-службы и т. Д.)?

В большинстве случаев ответ на поставленные выше вопросы звучит громко да . Но обратите внимание, что при реализации такого рода слабой связи это оказывает негативное влияние на производительность приложения ( Проектирование слишком далеко в будущее ). Поэтому мой совет: если приложение не требует слабой связи, не делайте этого. Остерегайтесь переподготовки !

Дополнительная информация

• Что такое «чрезмерная инженерия» применительно к программному обеспечению?
• Overengineering - Как этого избежать
• Разработка программного обеспечения с избыточным рисунком
• ОО Шаблоны проектирования

Answer 3

В терминах пуристической ОО вы можете утверждать, что класс Card может разумно отвечать за сам рисунок.

Однако вы почти всегда хотите разделение интересов , которое приводит к * 1005Подход * MVC или аналогичный, согласно которому логика, управляющая поведением карты, и код для визуального представления карты находятся в разных классах.

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