The appearance model
Facade pattern: Facade, which hides the complexity of the system and provides an interface to the customer to access the system, providing an interface to the series of interfaces of the subsystem that makes it easier to access or use the subsystem.
I. Roles and usage scenarios
Simply put, this mode is to encapsulate some complex processes into an interface for external users to use more easily. In this mode, three characters are designed. 1). Facade characters: the core of the facade pattern. It is invoked by the customer role, which is familiar with the subsystem’s functionality. Several combinations of functions are predetermined internally based on the needs of the customer role. (Computer) 2). Subsystem role: Realizing the functions of subsystems. It is unknown to the customer role and Facade. It can have internal interaction within the system, but also can be called by the external interface. (CPU Disk Memory) 3). Customer role: Call Facede to complete the function to be implemented.
Usage Scenarios:
1- modules that provide external access to complex modules or subsystems;
2- Subsystems are independent of each other;
3- In the hierarchy, you can define the entry to each layer of the system using a facade pattern.
Two, code examples
Every Computer has a CPU, Memory, and Disk. As the Computer is turned on and off, the corresponding parts are also turned on and off, so using this facade decouples the user from the parts. Such as:
2.1. Subsystem Roles
public class CPU { public void start() { System.out.println("cpu is start..." ); } public void shutDown() { System.out.println("cpu is down..." ); } } public class Disk { public void start() { System.out.println("disk is start..." ); } public void shutDown() { System.out.println("disk is down"); } } public class Memory { public void start() { System.out.println("memory is start..." ); } public void showDown() { System.out.println("memory is down..." ); }}Copy the code
2.2 the facade class
package com.chb.h.FacadeDesignPattern; public class Computer { private CPU cpu; private Disk disk; private Memory memory; public Computer() { cpu = new CPU(); disk = new Disk(); memory = new Memory(); } public void start() { System.out.println("Computer is starting..." ); cpu.start(); disk.start(); memory.start(); System.out.println("Computer start end"); } public void shutDown() { System.out.println("Computer begin shutdown"); cpu.shutDown(); disk.shutDown(); memory.showDown(); System.out.println("Computer shutDown end..." ); }}Copy the code
The test class c
/** Appearance mode: Facade, which hides the complexity of the system and provides an interface to the customer to access the system, to provide an interface to the series of interfaces of the subsystem that makes it easier to access or use, */ public class Test { public static void main(String[] args) { Computer computer = new Computer(); computer.start(); System.out.println("======================"); computer.shutDown(); }}Copy the code
As we can see from the above example, with this Facade class, the Computer class, the user does not have to personally invoke the Disk,Memory, and CPU classes in the subsystem, and does not need to know the implementation details of the internal system, or even the internal structure of the system. The client only needs to interact with the Facade.
Four advantages,
-
Loose coupling \
- Decoupling between the client and subsystem makes it easier to expand and maintain module functions within the subsystem;
-
Easy to use \
- The client doesn’t need to know the implementation inside the subsystem at all, or the composition inside the subsystem at all, it just needs to interact with the Facade class.
-
Better partition of access hierarchies \
- Some methods are used outside the system, and some methods are used inside the system interactively. The subsystem concentrates the functions exposed to the outside into the facade, which can be used by the client and hides the details inside the subsystem.