Can it be beneficial to include graphics capabilities in model classes?

Question

Is it beneficial in OO design to include drawing capabilities in otherwise model classes?

To give an example, on a university project, I have to develop an implementation of the board game 'ticket to ride'. In there, I have a Card class called AbstractCard, to represent a card in the game, subclassed by TrainCard and DestinationCard. The AbstractCard class would look like this:

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

The subclasses add extra data and methods.

John Topley · Answer 1 · 2011-09-08T13:57:31.180

In purist OO terms you could argue that a Card class could reasonably be responsible for drawing itself.

However, you almost always want a separation of concerns which leads to an MVC approach or similar, whereby the logic governing how a card behaves and the code for rendering a visual representation of a card are in different classes.

There are several advantages to this approach, including (but not limited to) each class having higher cohesion because it doesn't have multiple responsibilities, and it being easier to test in isolation a model class that only contains pure business logic.

score 0 · Answer 2 · answered Sep 08 '11 at 13:50

IN GENERAL:

No, this will be a hindrance later on. Try to keep your presentation (drawing / layout) separate from your logic (models).

That way later you can revamp the graphics without having to risk having to rewrite your business logic.

Instead, provide smart interfaces between your logic, and presentation layers so that you have a fluid interface between them. This should give all of the benefits of combining them without any of the hindrance.

score 0 · Accepted Answer · edited May 23 '17 at 11:43

There is no hard and fast rule that you MUST separate out the business logic from the UI.

Ask yourself these questions:

What is the probability that the class that you are designing will be modified in the future?
Will it add other user interfaces (views) in the future (like accessing the business logic through the web services, etc.)?

In most of the cases the answer to the above questions is a resounding yes. But note that there is negative impact on the performance of the application when you implement this sort of loose coupling (Designing Too Far Into The Future). So my advice is unless the application has a requirement for loose coupling do not make it so. Beware of overengineering!

More information

Can it be beneficial to include graphics capabilities in model classes?

3 Answers3

IN GENERAL: