Viewing design Patterns from Java class libraries (5)

With the basics of many of the previous design patterns, here you can propose a more specific pattern of MVC. MVC is not part of Gof's 23 design patterns, but it was presented as an important example in Gof's book and was highly rated. Generally speaking, we think that the 23 models of GOF are some intermediate mode, under it can also abstract some more general low-level mode, on which can also be combined to get some advanced mode. MVC can be seen as the result of a combination of patterns (in fact, MVC occurs earlier than the design pattern, but only on the basis of the design pattern). It may be difficult to understand MVC without the preceding foundation.

MVC pattern

The MVC pattern is more special, its meaning is more broad, the level involved is not only the design of this piece, it is not easy to classify it as a design pattern. Of course, it's mostly referred to as a design concept, and MVC has a vital role to play in the Java system. Here is the Java design pattern, of course, it is not easy to pull it off.

As for the ins and outs of MVC, this is no longer the story. Here the main s is about two aspects: MVC as a design pattern and MVC as an architectural pattern.

MVC refers to a method of dividing a system into three parts: a system.

Model: Encapsulates the data source and all operations based on that data. In a component, model often represents a method of the state and operation State of a component.

View: Encapsulates a display of the data source model. A model can be made up of multiple views, and a view can theoretically be associated with different models.

Controller (Control): encapsulates an external action on the model. Typically, these actions are forwarded to the model and call one or more of the corresponding methods in the model. General controller in model and view between the role of communication, processing users in view input, and to the model. This can be loosely coupled between the model and view, and can even not know each other, and the two parts are connected by controller.

With the many patterns described earlier, it is easy to explain the intrinsic behavior of MVC through patterns. As I said earlier, in design mode, MVC is actually a higher-level pattern, combined by a number of more basic design patterns, where the model-view relationship is actually a observer pattern, the state of the model and the attempted display respond to each other, and view- Controller is described by the strategy model, view uses a specific controller instance to implement a specific response strategy, replacing different controller and changing the view's response to user input. Other design patterns are easily integrated into the system. For example, you can combine multiple view nesting through the composite mode, specify the view's controller through the FactoryMethod mode, and so on.

The benefit of using MVC is that, on the one hand, separating data and its representations makes it easy to add or remove a user view, even when the program is executing. Model and view can be developed individually, adding to the maintainability, scalability, and ease of testing of the program. On the other hand, separating the control logic from the performance interface allows the program to dynamically select different user interfaces according to workflow, user habits, or model state at runtime.

Swing is supposed to be designed entirely in the way of MVC. Before the design begins, the goals that swing wants to achieve include:

Model-driven (model-driven) programming approach.

Provides a single set of APIs, but can support multiple visual senses (Look-and-feel) to provide users with different interfaces.

It is natural to find that using the MVC pattern can help achieve the above two goals.

Strictly speaking, MVC in swing is actually a variant of MVC: M-VC. Only the model interfaces that are shown in swing are part of the mechanism that integrates views and controllers in a single UI object. View and control are loosely grouped together, and more logic is introduced in the Event Listener section.

However, this does not preclude the essence of MVC in swing. In fact, swing was actually designed in the standard MVC pattern in the early stages of swing development, but the immediate problem arose: view and controller were actually tightly coupled, and it was hard to make a generalized controller that adapted to different view, And, generally, there is no great need.