A single class provides both model, view, and controller logic

How does it work?

This pattern is characterized by its lack of separation between domain model and view code.


  • Simple GUI applications

When should you use it?

  • When maintenance of the application is not a factor of importance, because its stays small.


If the pattern is used in larger projects, the following problems start to occur
  • Access and modification of the current state from outside is cumbersome, being contained into the all-encompassing visual object: external objects that want to modify the current counter need to make sure that the represented value is synchronized, for example, forcing a call to _update(), or having the Counter object provide a setValue() method
  • It is difficult for other visual objects to report the same information, maybe with two different visual aspects (e.g. both as a counter and as a progress bar)
  • The resulting class is difficult to test. The only way to stress it through its public interface and functionality is to actually probe it with GUI events, which is impractical for reasons we will examine later.
  • The logic dealing with visual aspect (i.e. handling and layouting widgets, updating the label on the button), interaction aspect (handling the user initiated mouse click to perform the increment operation) and business aspect (incrementing the counter) are of different nature, and would be better kept separated. This would ease testability, simplify code understanding and interaction.