Design pattern (structural type) appearance pattern (facade pattern)

PS One sentence: Eventually choose Csdn to organize the publication of the knowledge points of these years, the article parallel migration to CSDN. Because CSDN also support markdown grammar, Ah!

"Craftsman Joshui Http://blog.csdn.net/yanbober" read the previous article, "Design pattern (structural type) of the decorator mode (Decorator pattern)" http://blog.csdn.net/yanbober/ article/details/45395747

Overview

A customer class needs to interact with more than one business class, and these business classes often appear as a whole, resulting in more complex code when used because of the many analogies involved. The appearance mode implements this function by introducing a new skin class (facade), which provides a unified portal for calls from multiple business classes, simplifying the interaction between classes. If there is no appearance class, then each customer class needs to have a complex interaction with multiple business classes, and the system will have a high degree of coupling. The appearance pattern is a concrete realization of the Dimitri law, which can reduce the complexity of the original system by introducing a new appearance character, and reduce the coupling degree of the customer class and subsystem.

Core

Concept: provides a unified portal for a set of interfaces in a subsystem. The appearance pattern defines a high-level interface that makes this subsystem easier to use.

key: appearance mode structure important core module:

Appearance role

The client can call its method, in the appearance role can know the function and responsibility of the relevant subsystem, under normal circumstances, it will all the requests from the client to the corresponding subsystem, passed to the corresponding Subsystem object processing.

subsystem roles

In the software system can have one or more subsystem roles, each subsystem can not be a separate class, but a collection of classes, it implements the function of the subsystem, each subsystem can be called directly by the client, or called by the skin role, it processing by the appearance of the request sent by the class subsystem does not know the appearance of the existence of the subsystem, the appearance of the role is just another client only.

Usage Scenarios

Provides a simple entry when you need access to a complex set of subsystems.

There is a large dependency between the client program and several subsystems. The introduction of the appearance class can decouple the subsystem from the client, thus improving the independence and portability of the subsystem.

In a hierarchical structure, you can use the appearance pattern to define the entry of each layer in the system, and the layers are not directly related to the layers, but the contact is established through the appearance class to reduce the coupling between the layers.

Program Ape Instance

It also illustrates the appearance pattern with the example of a bitter-forcing program ape. An Android developer developing Android programs requires a lot of tool conditions, computer, software, and networking. Implemented as follows:

 PackageYanbober.github.io;//SUBSYSTEM roleClass Computer { Public void ThinkPad() {System.out.println ("Computer is thinkpad!"); }}class Eathnet { Public void Net() {System.out.println ("Net is cmcc!"); }}class Developertools { Public void Tools() {System.out.println ("Developer Tool is Android studio!"); }}//Appearance roleClass Androiddeveloperequipment { Public void Equipment() {NewComputer (). ThinkPad ();NewEathnet (). NET ();NewDevelopertools (). Tools (); }} Public  class Main {     Public Static void Main(string[] args) {Androiddeveloperequipment dev =NewAndroiddeveloperequipment ();    Dev.equipment (); }}

sum up a

Appearance Mode Advantages:

• Reducing the number of objects the client needs to process makes it easier to use the subsystem.
• The loosely coupled relationship between subsystem and client is realized.
• The modification of one subsystem has no effect on other subsystems, and the internal changes of the subsystem do not affect the Appearance object.

Appearance Mode Disadvantages:

• It is not very good to restrict the use of subsystem classes directly by clients, which reduces variability and flexibility if there are too many restrictions on the client Access subsystem classes.
• If the design is inappropriate, adding new subsystems may require modifying the source code of the appearance class, violating the open and closed principle.

"Craftsman Joshui Http://blog.csdn.net/yanbober" Continue reading "to be continued ... 》

Design pattern (structural type) appearance pattern (facade pattern)