Small talk about design patterns (13)—Appearance pattern

Column introduction

Column address

link

Column introduction

It mainly analyzes and summarizes the 23 common design patterns currently on the market one by one. I hope that interested friends can take a look and it will be continuously updated. I hope you can supervise me and we can learn and make progress together. Come on, everyone.
Insert image description here

appearance mode

Facade Pattern is a structural design pattern that provides a unified interface for accessing a set of interfaces in a subsystem. The facade pattern defines a high-level interface that makes subsystems easier to use.

main purpose

Simplify interfaces to complex systems. It hides the complexity of subsystems by providing a unified interface, making it easier for clients to use the system. The facade pattern reduces system complexity by decoupling the client from subsystems and providing a simplified interface.
Insert image description here

role analysis

Facade role

Appearance characters are the core of Appearance mode. It knows which subsystem classes are responsible for handling requests and delegates client requests to the appropriate subsystem objects. Facade roles are usually singleton patterns that provide a simple interface and hide the complexity of subsystems.

Subsystem role

Subsystem roles are individual subsystem classes in the appearance pattern. They are the classes that actually handle requests and complete specific functions. The appearance role delegates the client's request to the appropriate subsystem object, and the subsystem object completes the specific operation.

Client role

Client roles are classes that use the appearance pattern. It does this by calling the interface of the appearance role without having to interact directly with the subsystem class. The client role only needs to know the simple interface provided by the facade role and does not need to understand the complexity of the subsystem.

Insert image description here

working principle

The client operates by calling the interface of the appearance role. The appearance role delegates the request to the appropriate subsystem object. The subsystem object completes the specific operation and returns the result to the client. The client does not need to understand the complexity of the subsystem and only needs to access the subsystem through the facade role. This can reduce the complexity of the system and improve the maintainability and scalability of the system.

Summary of core ideas

Simplified interface

The appearance role provides a simplified interface that encapsulates a set of interfaces of the subsystem, making it easier for clients to use the system. The client only needs to call the interface of the appearance role and does not need to understand the complexity of the subsystem.

Decouple clients and subsystems

The appearance pattern decouples the client from the subsystem. The client only needs to interact with the appearance role and does not need to interact directly with the subsystem class. This can reduce the complexity of the client while also improving the maintainability and scalability of the system.

Hide implementation details

The facade pattern hides the implementation details of the subsystem and exposes only a simple interface to the client. This protects the implementation details of the subsystem and prevents clients from directly accessing and modifying the subsystem's internal implementation.
Insert image description here

Java program implementation

// 子系统类A
class SubsystemA {
    
    
    public void operationA() {
    
    
        System.out.println("SubsystemA operation");
    }
}

// 子系统类B
class SubsystemB {
    
    
    public void operationB() {
    
    
        System.out.println("SubsystemB operation");
    }
}

// 外观类
class Facade {
    
    
    private SubsystemA subsystemA;
    private SubsystemB subsystemB;

    public Facade() {
    
    
        subsystemA = new SubsystemA();
        subsystemB = new SubsystemB();
    }

    public void operation() {
    
    
        subsystemA.operationA();
        subsystemB.operationB();
    }
}

// 客户端类
public class Client {
    
    
    public static void main(String[] args) {
    
    
        Facade facade = new Facade();
        facade.operation();
    }
}

program analysis

In the above example, we defined two subsystem classes SubsystemA and SubsystemB, which implement different operations respectively. Then we defined a facade class Facade, which encapsulates the subsystem class and provides a simplified interface operation. The client class Client uses appearance classes to complete operations without directly interacting with subsystem classes.
Insert image description here

Advantages and Disadvantages Analysis

advantage

Simplify client operations

The facade pattern provides a simplified interface that hides the complexity of subsystems and makes it easier for clients to use.

Decouple clients and subsystems

The appearance mode decouples the client from the subsystem. The client only needs to interact with the appearance class and does not need to interact directly with the subsystem class, which reduces the complexity of the client.

Improve system availability and maintainability

The appearance pattern encapsulates the implementation details of the subsystem, protects the implementation details of the subsystem, and makes the system more stable and maintainable.
Insert image description here

shortcoming

May cause the system to become more complex

When a system becomes complex, facade classes can become large and difficult to maintain.

limits flexibility

Facade mode hides the complexity of the subsystem, but also limits the client's flexible access to the subsystem.

Summarize

The appearance pattern has great advantages in simplifying client operations, decoupling clients and subsystems, and improving system availability and maintainability. It is suitable for situations where complex subsystems need to be hidden. However, care needs to be taken during design to avoid appearance classes becoming large and overly complex, and to trade off flexibility and encapsulation.Insert image description here

Guess you like

Origin blog.csdn.net/weixin_74888502/article/details/133498872