Design Patterns: Compound Pattern

1. What is the Compound Pattern?

In form, the Compound Pattern is indeed a combination of multiple patterns, but satisfying this condition alone does not make it a Compound Pattern. Note its definition:

Combine multiple patterns to form a "framework" to solve general problems. When mentioning "framework", one easily thinks of MVC, and indeed MVC is a classic Compound Pattern.

2. MVC and the Compound Pattern

Responsibilities of Model, View, and Controller:

Here I must emphasize the difference between control logic and application logic (algorithmic logic):

• Control logic refers to determining which object's which method should be called in the current scenario
• Application logic refers to the internal implementation of a specific object's specific method (a complex algorithm, or a series of concrete processing steps)

(To be precise, View also contains a bit of control logic (determining which Controller to call based on user actions), but under normal circumstances we ignore this small amount of logic)

The greatest advantage of MVC is separating the presentation layer View from the model Model, achieving loose coupling in design (accommodating changes) and code reusability (View can be easily replaced, only needing to modify that tiny bit of control logic in the new View)

As mentioned earlier, MVC is a Compound Pattern. So which patterns does it actually combine? Let's examine:

• Observer Pattern: V and C are both observers of M (when Model's state updates, it should promptly notify V to update the view, or notify C to perform corresponding logical processing)
• Strategy Pattern: C is V's "strategy", so the control logic contained in V is "selecting strategy", that is, selecting the Controller
• Composite Pattern: V's own implementation applies the Composite Pattern (calling the repaint method of the top-level container causes all components within the container to be repainted)

MVC applies multiple patterns and can effectively solve general design problems, so it is called a Compound Pattern

3. Traditional MVC vs. Java Local Application MVC

From the above, we can see that in traditional MVC, specific application logic is contained within M. That is, our model objects not only have a series of properties (and getters, setters) but also related data processing methods

This differs from MVC in Java local programs. In Java programs, we create packages to structure our code into layers, generally like this:

It needs to be explained that:

• The vo package generally contains classes abstracted from various entities (some also name the package bean, but the meaning is the same, containing only the properties of each entity and their corresponding getters and setters, without application logic)
• Both dao and core are auxiliary layers of service, and the three layers together map to Controller

The biggest difference between Java local program MVC and traditional MVC is that M in Java is more pure (clean), containing only value objects without any application logic. Almost all logic is placed inside Controller (various Concrete Service classes)

Written at the end:

There are far more mature frameworks applying the Compound Pattern than just MVC. It's just that I haven't encountered other frameworks yet, so I dare not comment rashly

When facing an unfamiliar framework, we might as well analyze its internal implementation from a design perspective, such as which design patterns are applied, the functions of each layer, and interactions between layers, etc.

Understanding some basic design patterns helps us quickly accept a framework. Only when we understand the internal implementation of a framework can we better master it.