This is the 11th day of my participation in the August Wenwen Challenge.More challenges in August

Dr. Yan Hong’s Book JAVA and Patterns begins by describing the Facade pattern as follows:

Facade pattern is a structural pattern of objects, and external communication with a subsystem must be carried out through a unified facade object. Facade mode provides a high-level interface that makes subsystems easier to use.

The Facade mode, also known as the Facade mode, provides simple interfaces for clients to use complex systems through the packaging of Facade classes, so as to reduce the complexity of clients. The Facade class provides an upper-level interface that integrates and encapsulates the methods of individual subsystems for use by clients. The client only needs to interact directly with the facade role, and the complex relationship between the client and the subsystem is realized by the facade role, thus reducing the coupling degree of the system.

Above, we also mentioned the definition of appearance class, which encapsulates many complex subsystem interfaces to provide simple interfaces for the client to use. This is similar to the tool classes we encountered in the actual development process. Here we will introduce the appearance class, tool class and example class.

  • A facade is a class that contains functionality halfway between a toolkit and a full application, providing easy usage for classes in a toolkit or subsystem.
  • Utility classes: Classes in the Java class library whose methods are all static;
  • Sample class: a complete application;

Appearance mode consists of two main roles:

  • Facade: Encapsulates subsystem interfaces for use by clients;
  • SubSystem: Can have one or more subsystems at the same time. Each subsystem is not a single class but a collection of classes (the subsystem above is a combination of ModuleA, ModuleB, and ModuleC classes). Each subsystem can be invoked directly by a client or by a facade role.

UML diagrams

Example code: subsystem

/** * subclass system A *@author dsw
 *
 */
class SubSystemA{
	public void createA(a){
		System.out.println("createA()");
	}
	
	public void drawSystemA(a){
		System.out.println("drawSystemA()"); }}/** * subclass system B *@author dsw
 *
 */
class SubSystemB{
	public void createB(a){
		System.out.println("createA()");
	}
	
	public void drawSystemB(a){
		System.out.println("SubSystemB()"); }}Copy the code

Appearance of the class

/** * appearance class, used to abstract subclass interface *@author dsw
 *
 */
public class FacadeMaker {
	private SubSystemA subSystemA;
	private SubSystemB subSystemB;
	
	public FacadeMaker(a){
		subSystemA = new SubSystemA();
		subSystemB = new SubSystemB();
	}
	
	
	public void createAndDrawA(a){
		subSystemA.createA();
		subSystemA.drawSystemA();
	}
	
	
	public void createAndDrawB(a){ subSystemB.createB(); subSystemB.drawSystemB(); }}Copy the code

The client

public class Client {
	
	public static void main(String []args){
		FacadeMaker facadeMaker = newFacadeMaker(); facadeMaker.createAndDrawA(); facadeMaker.createAndDrawB(); }}Copy the code

Summary of appearance patterns

advantages

  • Reduce system interdependence. The Facade encapsulation reduces the coupling between the client system and the subsystem, making the subsystem more independent and easier to maintain.
  • Easy to use, so that the client is more simple to use the system, do not have to understand the internal implementation of the system.
  • Through the proper use of Facade, we can better divide the layers of access. Expose or hide implementation details of the subsystem for client requirements.

disadvantages

  • Inconsistent with the opening and closing principle. The appearance class needs to be modified when a new subsystem is added or removed. This problem can be solved to some extent by introducing abstract appearance classes, against which the client programs