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.
There is no hard and fast rule that you MUST separate out the business logic from the UI.
Ask yourself these questions:
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