Analysis of Appearance Mode of Design Pattern

Today is the eighth article in the design pattern learning series- appearance pattern .

Opening question

1. What is appearance mode?
2. What is the difference between appearance mode and adapter mode?

Appearance mode analysis

First of all, let's look at a scene. We must usually use the bank's app. When registering, we must go through the step of real-name authentication. But the real name function is very complicated, including different steps such as secret verification, uploading certificates, OCR recognition, and online verification. If a client wants to use the real-name function, if he wants to connect one by one, the head will be big, and the connection is so complicated. How to do?

Next, let's take a look at how the appearance model can solve this mess, so that platform customers can easily use the real-name function.

With the appearance mode, by implementing an appearance class that provides a more reasonable interface, we can make the subsystems involved in our complex real-name process easier to use.

code show as below:

public class RealNameSysFacade {
    
    
    PassVerify pvf;
    UploadCer uc;
    OCRIdentify ocri;
    OnlineVer ov;

    public RealNameSysFacade(PassVerify pvf, UploadCer uc, OCRIdentify ocri, OnlineVer ov) {
    
    
        this.pvf = pvf;
        this.uc = uc;
        this.ocri = ocri;
        this.ov = ov;
    }
    
    public boolean realNameVerify(Request request) {
    
    
        System.out.println("get ready to realname ...");
        pvf.process();
        uc.process();
        // 其他方法
    }
}

Features customers use real names, just call RealNameSysFacadethe realNameVerify () method can be. This is the simplified interface, and everything is done by calling it.

Define appearance mode

Provides a unified interface to access a group of interfaces in the subsystem. The appearance defines a high-level interface to make the subsystem easier to use.

The above concepts are easy to understand, but please remember the intent of the pattern is to provide a simple interface to make a subsystem easier to use. This can also be felt from the following class diagram:

That's it for all the content. Isn't it simple? Congratulations on learning another design pattern!

Now we come to learn a new OO design principle.

Least knowledge principle : only talk to your close friends.

This is a bit humane. To put it bluntly, we hope that we don’t couple too many classes together in our design. We often see changes to a class in the system and find that there are calls everywhere. This is a headache and the maintenance cost is also very high. High, it is not easy for newcomers to understand and they dare not change.

Here you may ask, what is the specific method of this principle? How to meet the minimum knowledge principle?

Here I enumerate for you, for any object class, in the method call within the object, we should only call the following methods:

1. The object itself
2. The object passed in as a method parameter;
3. Any objects created or instantiated by this method;
4. Any component of the object;

The first three guidelines tell us that if it is an object returned by calling other methods, we should not call the method of that object! The fourth is to think of "component" as any object referenced by instance variables, in other words, think of this as "has one" (HAS-A) relationship.

The difference between appearance mode and adapter mode

You may feel that the appearance model also combines some components to provide a unified interface to the outside, and the adapter also combines other components to provide a target interface to the outside, but the starting points of the two are different;

1. When you need to use an existing class and its interface does not meet your needs, use an adapter;
2. When you need to simplify and unify a large interface or a group of complex interfaces, use the appearance;
3. The adapter changes the interface to meet customer expectations;
4. The appearance decouples the customer from a complex subsystem;
5. Implementing an adapter may take some effort or effort, depending on the size and complexity of the target interface;
6. To realize an appearance, you need to combine the subsystems into the appearance, and then delegate the work to the subsystem for execution;
7. More than one appearance can be realized for a subsystem. If the subsystem is too complex, it can be divided into multiple levels;

---

I believe that after reading the description of this article, you should have mastered another design pattern. Congratulations! Remember to review it regularly in your mind with questions, form your own knowledge system, and then combine it with daily practice, otherwise it is easy to forget.

The full text is over, fighting!