An overview,

Providing a consistent interface for a set of interfaces in a subsystem, the Facade pattern defines a high-level interface that makes the subsystem easier to use. We all know that the lower the class-to-class coupling, the better the reusability. If two classes don’t have to talk to each other, don’t let the two classes interact directly with each other. If you need to call a method inside the class, a third party can forward the call. The appearance pattern is a good illustration of this. The facade pattern provides a unified interface to access a set of interfaces in a subsystem. It minimizes the interdependencies between an application’s sub-systems by providing a simple, single barrier through which customers communicate with subsystems. The use of facade patterns makes it easy for customers to reference subsystems, enabling loose coupling between customers and subsystems. But it violates the “open close principle,” because adding a new subsystem might require modifying the facade class or client source code.

Two, use scenarios

1. When you want to provide a simple interface to a complex subsystem. Subsystems tend to become more and more complex as they evolve. Most patterns produce more and smaller classes when used. This makes subsystems more reusable and easier to customize, but it also creates some difficulties for users who don’t need to customize subsystems. A Facade can provide a simple default view that is sufficient for most users, while those who need more customization can bypass the Facade layer.

2. There is a significant dependency between the client program and the implementation part of the abstract class. Introducing a facade to separate this subsystem from customers and other subsystems improves subsystem independence and portability.

3. When you need to build a hierarchical subsystem, use the facade pattern to define the entry points for each layer in the subsystem. If subsystems are interdependent, you can simplify their dependencies by having them communicate only through the facade.

Iii. Participants

1.Facade knows which subsystem classes are responsible for handling requests. Proxy the customer’s request to the appropriate subsystem object.

2.Subsystemclasses implement the functions of subsystems. Processes the tasks assigned by the Facade object. No information about facade; There is no pointer to the facade.

Fourth, the class diagram

Five, code examples

1.Facade

/** * Facade * @author zhipeng_Tong */ public class Facade { private ServiceA serviceA; private ServiceB serviceB; private ServiceC serviceC; public Facade() { this.serviceA = new ServiceA(); this.serviceB = new ServiceB(); this.serviceC = new ServiceC(); } public void methodA() { serviceA.method(); serviceB.method(); } public void methodB() { serviceB.method(); serviceC.method(); } public void methodC() { serviceA.method(); serviceC.method(); }}Copy the code

2.Subsystemclasses

/** * SubSystem * @author zhipeng_Tong */ public class ServiceA {public void method() {system.out.println (" here is ServiceA "); }}Copy the code
/** * SubSystem * @author zhipeng_Tong */ public class ServiceB {public void method() {system.out.println (" here is ServiceB "); }}Copy the code
/** * SubSystem * @author zhipeng_Tong */ public class ServiceC {public void method() {system.out.println (" here is the ServiceC "); }}Copy the code

3. Test code:

public class Client { public static void main(String[] args) { Facade facade = new Facade(); facade.methodA(); facade.methodB(); facade.methodC(); }}Copy the code

Running results:

Here's service A here's service B here's service B here's service C here's service A here's service CCopy the code