Java/android Design Patterns Learning Notes---appearance mode

This blog introduces the appearance pattern (facade pattern), the appearance mode is also called the façade pattern, it is used very frequently in the development process, especially the third party SDK basically very big probability will use the appearance pattern. Through an appearance class, the whole subsystem has only one unified high-level interface, which can reduce the user's usage cost, and also block many implementation details for the user. Of course, in our development process, the appearance mode is also our common means of encapsulating API, such as network module, Imageloader module and so on. In fact, we may have used many of the appearance patterns in the development process, but did not understand it from the theoretical level.
Reprint Please specify source: http://blog.csdn.net/self_study/article/details/51931196.
PS: The technology is interested in the same shoe plus group 5,446,459,721 Exchange.

Total catalog of design patterns

Java/android design mode Learning Notes directory

features

　　The appearance mode provides a unified interface for accessing a group of interfaces in a subsystem, and the appearance defines a high-level interface that makes the subsystem easier to use.
Usage scenarios for appearance modes:

• Provides a simple interface for a complex subsystem. Facade can provide a simple and unified interface, the specific implementation of the external hidden subsystem, isolation changes.
• 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 allow them to communicate only through the facade interface, simplifying their dependencies.

The appearance mode simplifies the interface and allows us to avoid tight coupling between the client and the subsystem.

UML class Diagram

The appearance mode does not have a generalized class diagram description, we first use a structure diagram to illustrate:
　　
Abstract a class diagram according to the structure diagram:

The appearance mode has two characters:

• Facade role: The system external interface, the client connection subsystem functions of the portal.
• subsystem role (SUBSYSTEM) role: You can have one or more subsystems at the same time, each subsystem is not a separate class, but a collection of classes. Each subsystem can be called directly by the client or by a façade role. Subsystems do not know the presence of the façade, for the subsystem, the façade is just another client only.

We can write out the general code of the appearance pattern according to the UML class diagram above:
Subsystem:

public   Class  SystemA {public  void  operation1  () {system.    Out . Print ( "systema:operation1\n" ); } public  void   Operation2  () {system.    Out . Print ( "systema:operation2\n" ); } public  void   Operation3  () {system.    Out . Print ( "systema:operation3\n" ); }}

public   Class  Systemb {public  void  operation1  () {system.    Out . Print ( "systemb:operation1\n" ); } public  void   Operation2  () {system.    Out . Print ( "systemb:operation2\n" ); } public  void   Operation3  () {system.    Out . Print ( "systemb:operation3\n" ); }}

publicclass SystemC {    publicvoidoperation1(){        System.out.print("SystemC:operation1\n");    }    publicvoidoperation2(){        System.out.print("SystemC:operation2\n");    }    publicvoidoperation3(){        System.out.print("SystemC:operation3\n");    }}

Then the Appearance object Ifacade.class

publicinterface IFacade {    void operationA();    void operationB();    void operationC();}

Facade.class

 Public  class facade implements ifacade{    PrivateSystemA SystemA =NewSystemA ();PrivateSystemb Systemb =NewSystemb ();PrivateSystemC SystemC =NewSystemC ();@Override     Public void Operationa() {systema.operation1 ();        Systemb.operation2 ();    Systemc.operation3 (); }@Override     Public void operationb() {systema.operation2 ();        Systemb.operation1 ();    Systemc.operation3 (); }@Override     Public void Operationc() {systemc.operation1 ();        Systemb.operation2 ();    Systema.operation3 (); }}

The final Test code:

publicstaticvoidmain(String args[]) {    new Facade();    facade.operationA();    facade.operationB();    facade.operationC();}

The resulting output is as follows:

Example and source code

Here is a direct display of a simple computer startup pseudo-code to represent:

/ * Complex parts * /Class CPU { Public void Freeze() { ... } Public void  Jump(LongPosition) {...} Public void Execute() { ... }} Class Memory { Public void Load(LongPositionbyte[] data) {...}} Class Harddrive { Public byte[]Read(LongLbaintSize) {...}}/ * facade * /Class Computerfacade {PrivateCPU processor;PrivateMemory RAM;PrivateHarddrive HD; Public Computerfacade() { This. processor =NewCPU (); This. Ram =NewMemory (); This. HD =NewHarddrive (); } Public void Start() {processor.freeze ();        Ram.load (Boot_address, Hd.read (Boot_sector, sector_size));        Processor.jump (boot_address);    Processor.execute (); }}/ * Client * /Class You { Public Static void Main(string[] args) {Computerfacade computer =NewComputerfacade ();    Computer.start (); }}

Summary

The appearance mode is a high frequency use design pattern, it is the essence lies in the encapsulation two words. A high-level structure to provide users with a unified API portal, so that the user through a type of the basic ability to operate the entire system, which reduces the user's cost of use, but also to improve the system flexibility.
The appearance class follows a very important design pattern principle: The Dimitri principle (least knowledge principle), which allows clients to rely on the fewest classes, directly depending on the skin class rather than relying on all the subsystem classes.
Advantages:

• The client program hides subsystem details, thus reducing the customer's coupling to the subsystem and embracing change;
• The appearance class to the subsystem's interface encapsulation, makes the system more easy to use;
• Better division of access levels, through the rational use of facade, can help us to better divide the level of access. Some methods are external to the system, and some methods are used internally by the system. The ability to expose external functionality to the Appearance class makes it easy for clients to use and to hide internal details.

Disadvantages:

• The Appearance class interface expands, because the subsystem interface all by the appearance class unifies the external exposure, causes the Appearance class API interface to be more, increases the user cost to a certain extent;
• The appearance class does not follow the open and closed principle, and you may need to modify the appearance class directly when the business changes.

Adapter vs Decorator vs bridging vs Proxy vs appearance

These are structural design patterns, they are similar, they are easy to mix in the actual use process, we are here to give them a comparison:

Adapter Mode

Adapter mode and other three design patterns are generally not easy to confuse, it is the role of the original incompatible two classes together, UML diagram and other differences are very large.
UML Class Diagrams:
　　

Decorator Mode

The decorator pattern is structurally similar to the proxy pattern, but unlike the proxy mode, the decorator is used to dynamically add some extra responsibilities to an object, the adorner pattern adds behavior to the object, and the delegate Controls access.
UML Class Diagrams:
　　

Bridging Mode

The purpose of bridging mode is to separate the abstract and implementation parts so that they can change independently, so that they are independent of each other and are not implemented from the same interface, which is the difference between Bridge mode and proxy mode, decorator mode.
UML Class Diagrams:
　　

Proxy Mode

The proxy mode provides a representative for another object to control the client's access to the object, in many ways, such as remote agents and virtual proxies, which are not mentioned here, but decorator mode is intended to extend the object.
UML Class Diagrams:
　　

appearance mode

The appearance mode provides a unified interface for accessing a group of interfaces in a subsystem. The appearance defines a high-level interface that makes the subsystem easier to use.
The adapter pattern turns one or more class interfaces into an interface that the client expects, although most data uses an adapter that only fits a class, but you can adapt many classes to provide an interface for the client to access; Similarly, a façade pattern can provide a simplified interface for a class that has a complex interface. The difference between the two models is not that they "wrap" a few classes, but rather their intentions. The intent of the adapter mode is that the "change" interface conforms to the customer's expectations, whereas the intent of the façade mode is to provide a simplified interface to the subsystem.
UML Class Diagrams:
　　

Source Download

Https://github.com/zhaozepeng/Design-Patterns/tree/master/FacadePattern

References

Https://en.wikipedia.org/wiki/Facade_pattern
http://blog.csdn.net/jason0539/article/details/22775311

Java/android Design Patterns Learning Notes---appearance mode