Correctly implementing the MVC pattern in GUI development using Swing in Java
Solution 1:
MVC pattern it is a common paradigm, so there is no differences between pragramming languages in general. However the implementation and some terminologies sometimes look different. In Java Swing it is often to see two following approaches:
1. Classic MVC
Controller - Listens user interface actions, performs corresponding Model updates. Can listen actions from different Views.
Model - Represents the state and the domain logic, methods to modify the state. Notifies listeners about the model updates (several Views can listen the updates). Model is independent and knows nothing about the listeners and their logic.
View - Responsible for user interface, UI elements layout, also listens Model updates and update the graphic inteface if required. Has some knowledge about the model, in example shown below it knows how to process list of "items".
Design of some simple "To Do" app can look like:
2. MVP (Model View Presenter)
Controller acts as a Mediator between the View and the Model. View become very thin and knows nothing about the Model and interact with Controller only. Controller listens both View and Model and perform corresponding actions.
Swing itself adds some confusion because it uses MVC pattern for its UI components. Each UI control has a Model and View. It makes easier to design new UI components, however in a "big picture" of the whole Application design - UI controls stay on the View layer.
Solution 2:
Maybe I am misunderstanding, and everything should be done differently in different languages?
There is no misunderstanding; the pattern is merely applied differently.
As noted in a comment by @ordous and this this answer by @udalmik, a Swing application may have multiple implementations of the MVC pattern. As noted here and here, "not every interaction needs to pass through your application's controller." In contrast, a web application may well "have a 1:1 relation between views and controllers."
The Swing separable model architecture, cited here, "collapses the view and controller parts of each component into a single UI (user-interface) object." Swing controllers are scattered among the descendants of JComponent
, typically in the component's UI delegate. As a concrete example, BasicButtonUI
contains a BasicButtonListener
that handles user mouse interaction.
Almost used the answer in the link, but the fact that his controller extends
JPanel
ruined it, totally confused me there.
This can be confusing, as a simple Swing program may have no explicit controller at all. As suggested in this outline, the controller has direct access to any relevant view and model; it may also listen to user interaction with the view. The example was intended to illustrate the simplest such interaction. It is mere coincidence that the effect is evoked by user interaction with a view component. The simulation cited here, for example, has a ControlPanel
of view components that update the application's view and model. The DisplayPanel
listens directly for a ComponentEvent
that requires a model update. Etc.
Your application's controller is then free to focus on the application's needs.
@Marco13 elaborates on this and cites additional examples in this related answer.