Façade mode

Definition of Façade mode

Façade mode ( Facade pattern), also known as the appearance pattern, is a more commonly used encapsulation pattern, defined as

Under

Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level

Interface that makes the subsystem easier to use. (Requires that the outside of a subsystem must communicate with its internal

Over a unified object. Façade mode provides a high-level interface that makes subsystems easier to use. ）

The façade mode focuses on "unified Objects", which is the interface that provides an access subsystem, except that this interface does not allow

The behavior of any access subsystem occurs

Facade Façade role

The client can invoke the method of this role. This role knows all the functions and responsibilities of the subsystem. Under normal circumstances,

This role delegates all requests from the client to the appropriate subsystem, saying that the role has no actual business

Logic, just a delegate class.

subsystem Subsystem Role

You can have one or more subsystems at the same time. Each subsystem is not a separate class, but a set of classes

Compliance The subsystem does not know the presence of the façade. For subsystems, the façade is just another client.

Subsystem

public class ClassA {

public void Dosomethinga () {

Business logic

}

}

public class ClassB {

public void Dosomethingb () {

Business logic

}

}

public class ClassC {

public void DOSOMETHINGC () {

Business logic

}

}

Façade objects

public class Facade {

The object being delegated

Private ClassA a = new ClassA ();

Private ClassB B = new ClassB ();

Private ClassC C = new ClassC ();

methods to provide external access

public void MethodA () {

This.a.dosomethinga ();

}

public void MethodB () {

THIS.B.DOSOMETHINGB ();

}

public void Methodc () {

THIS.C.DOSOMETHINGC ();

}

}

Advantages of Façade mode

Façade mode has the following advantages.

Reduce system interdependencies

If we do not use the façade mode, the external access directly into the subsystem, between each other is a

strong coupling relationship, you die I will die, you live I can live, such a strong reliance is not acceptable system design, façade mold

is a good solution to this problem, and all dependencies are dependent on the façade object, regardless of the subsystem.

Increased flexibility

The dependence is reduced, and the flexibility naturally increases. Regardless of how the internal subsystem changes, as long as it does not affect the façade object,

Let your freedom of movement.

Improve security

Want you to access the subsystem of which business to open which logic, not open on the façade of the method, you can not access

To.

Disadvantages of Façade mode

The biggest drawback of the façade mode is that it does not conform to the opening and closing principle,

Usage scenarios for façade mode

Provides an interface for external access to a complex module or subsystem

subsystem is relatively independent--the external access to the subsystem as long as the black box operation can

Prevention of risk spread by low-level personnel

Considerations for Façade mode

1 A subsystem can have multiple facades

The façade is too big to bear.

Subsystems can provide different access paths

let's take the generic source code for the façade mode as an example. ClassA, ClassB, CLASSC is a subsystem of 3

Like, there are now two different high-level modules to access the subsystem, the module one can complete access to all business logic, but also

is in the general code. Facade class, which is the Trust module of subsystem, and module two belongs to the restricted Access object, can only visit

Ask the MethodB method, then how to deal with it? In this case, there is a need to create two facades for different high-rise models

Block to access, add a new façade to the original generic source to

New façade

public class Facade2 {

Referencing the original façade

Private facade facade = new facade ();

Methods of providing a unique access subsystem to the outside

public void MethodB () {

This.facade.methodB ();

}

}

the added façade is very simple and delegates to the existing façade object Facade to be processed, why use the Commission

Instead of writing a delegate-to-subsystem approach? That's because in object-oriented programming, try to keep the same

The code is written only once to avoid the tragedy of similar code being modified everywhere.

2 façade does not participate in the business logic within the subsystem

We

The logic on the METHODC on the door is modified, it must first call the ClassA Dosomethinga method, and then

called the DOSOMETHINGC method of ClassC

Modify the façade

public class Facade {

The object being delegated

Private ClassA a = new ClassA ();

Private ClassB B = new ClassB ();

Private ClassC C = new ClassC ();

methods to provide external access

public void MethodA () {

This.a.dosomethinga ();

}

public void MethodB () {

THIS.B.DOSOMETHINGB ();

}

public void Methodc () {

This.a.dosomethinga ();

THIS.C.DOSOMETHINGC ();

}

}

This design is very not reliable, why? Because you've got the façade object involved in the business logic, the door

A Polygon object simply provides a path to an access subsystem, and it should not and cannot participate in specific business logic, no

There is an upside-down problem: the subsystem must rely on the façade to be accessed, which is a serious mistake in design

Not only violates the principle of single responsibility, but also destroys the encapsulation of the system.

Having said so much, what should be done about this situation? Create a package class that is provided to the façade after encapsulation is complete

Encapsulation Class

public class Context {

Delegate processing

Private ClassA a = new ClassA ();

Private ClassC C = new ClassC ();

Complex calculations

public void Complexmethod () {

This.a.dosomethinga ();

THIS.C.DOSOMETHINGC ();

}

}

The role of this encapsulation class is to produce a business rule Complexmethod, and its living environment is in the subsystem

, only relies on two related objects, the façade object completes a complex business logic through its access

Façade class

public class Facade {

The object being delegated

Private ClassA a = new ClassA ();

Private ClassB B = new ClassB ();

Private Context context = new context ();

methods to provide external access

public void MethodA () {

This.a.dosomethinga ();

}

public void MethodB () {

THIS.B.DOSOMETHINGB ();

}

public void Methodc () {

This.context.complexMethod ();

}

}

After such a package, the façade object does not participate in the business logic, in the façade mode, the façade role should be

Stable, it should not change constantly, once a system is put into operation it should not be changed, it is a system external

interface, how do you make sure other modules are running stably? However, business logic is constantly changing, and I

We have encapsulated its changes within the subsystem, no matter how you change, to the outside visitors, are still the same

façade, the same approach -this is the structure the architect would most like to see.

Façade mode