Design patterns which separate datamodels and gui representation

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 vi开发者_开发知识库sitor 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?

---

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.

---

There is no "best" method, it all depends on you platform, architecture and other stuff. Usually, when it comes to GUI, several patterns should be combined. One of them is usually the MVC where the view can be extended with other hierarchy pattern (Visitor is also an option).

---

I think you might have success using strategy pattern, or composition.

With composition you can add the object responsible for drawing, no need to define it into the shape instance, and with strategy you can select the algorithm at runtime.

---

Yes, you're looking for the MVC pattern. Swing, for example, uses MVC. You define the model for tabular data in the TableModel interface. Then it is up to the Component how to render it. JTable renders it in a tabular fashion. A custom JPieChart can render it as a pie chart. The C in MVC stands for controller, and can let you update the model when the user interacts with the GUI.

---

A specialized case of MVC which might be of interest is Model View Presenter.

---

The Decorator Design Pattern can also be applied to GUI toolkits to add behaviors dynamically.