Design patterns which separate datamodels and gui representation

Question

Is there a design-pattern which is recognized as the best pattern to use when separating a datamodel and a gui drawing mechanism?

So say i have a class Circle and a class Square, then i would be tempted to have a draw method in both these classes. However that would force the class to import all kinds of nasty things depending on the drawing canvas im using (swing,j3d,opengl,etc).

My first thought would be that a Visitor pattern could solve this by making Square and Circle implement a method which takes a visitor as an input argument and calls a function on the visitor. then i could have two draw methods on the visitor which takes a Circle and a Square instance as input argument, and draws them accordingly.

Any suggestions on this?

Answer 1

The Model View Controller pattern is probably the most used. Swing relies heavily on this pattern, where Decorator (which is used for things such as scroll bars) and Strategy (layout managers etc.) seem to be the supporting patterns.

As for alternatives to MVC you can take a look at Model View Presenter, but in most implementations a full separation will rely heavily on an event bus of some sort, in the case of Swing in an Observer (event listeners) pattern.

The solution to datamodel/gui is seemingly a small problem, but it is actually quite hard to manage said event bus correctly.

My favorite way of doing it is relying on the Command pattern. Using an event bus to pass around different commands makes the separation somewhat clean. The datamodel executes the command in some fashion (usually using a related command handler object), and then the callback is called.

This is actually a glorified MVC, since the class executing the command ends up being your controller, but the pattern allows for the model/controller to only know about the callback objects. Depending on the nature of your program you could implement a set of classes, that only the view knows about using the Data Transfer Object pattern. This is my preferred approach to asynchronous applications such as GWT.

In desktop and Android applications, you still run asynchronous (Context.runOnUiThread() and SwingUtilities.invokeLater() dictate this), and therefore the command pattern fits right in. Whether or not DTOs are the best approach for your application depends, but they most certainly separate the model from the view.