The 7th chapter of the design pattern-appearance mode (Java implementation)

The 7th chapter of the design pattern-appearance mode (Java implementation)

　　"Fish brother, know how to put the elephant into the refrigerator?" (The author presses: This simple question still wants to test me, early hundreds of years.) It takes three steps to put the elephant into the refrigerator: the first step is to open the refrigerator door; the second step is to put the elephant in, and the third step, close the refrigerator door. "(Here imitate Motoyama teacher intonation, please self-brain fill)" Congratulations, answer right, then the question comes, if have 10,000 elephant to walk 30,000 steps? If there is a wrong order, is not the right to put in it? " In order to solve this problem, I-appearance pattern also emerged. (The author presses: Not a word to let me answer 、、、)

Self introduction of appearance mode

For me, it is a more common encapsulation pattern, defined as: Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem of easier to use. It translates to the requirement that the outside of a subsystem and its internal communication must be done through a unified object. The appearance mode provides a high-level interface that makes the subsystem easier to use.

I compare the main "Unified object", that is, to provide an interface to the access subsystem, in addition to this interface does not allow any access subsystem behavior occurs, the general class diagram is as follows:

　　

The client program communicates with the subsystem by sending a request to facade, and facade forwards the message to the appropriate subsystem object, although the object in the subsystem is actually working, but I must also convert his interface into a subsystem interface.

Self-analysis of the appearance pattern

I have the following advantages:

• Reduce system interdependencies. If I do not apply, then the outside world will directly access to the internal system, is strongly coupled with each other, you ask the strong coupling what? I tell you, strong coupling is die, what? You said it was romantic? No,no,no, strong reliance on the system design Chinese is not accepted. So if you see it, it means you're not far from refactoring.
• Increased flexibility. Dependence less, flexibility naturally improve, no matter how the system internal changes, as long as not affect the appearance of objects, I self-feuds.
• Improved security. I want you to access those business to open the logic, if not open, if you want to visit, windows are not.

　　there are advantages, and naturally there will be shortcomings. :

• The so-called disadvantage is not in line with the opening and shutting principle, open to expansion , the modification closed. Think of our implementation, after putting into use if the door object is found wrong, it can no longer solve, only the role code to modify the façade, this risk, do not need me to say more.

Implementation of the Appearance mode

　　Since the elephant, it is the elephant, the realization of the following-the first subsystem:

The first step is to open the refrigerator door subsystem:

1  Public class a{2      Public void Open () {3         System.out.println ("Open the refrigerator Door"); 4     }5 }

　　The second step is to put the elephant in the subsystem:

1  Public class b{2      Public void Pack () {3         SYSTEM.OUT.PRINTLN ("Load the Elephant in"); 4     }5 }

　　The third step is to close the refrigerator door subsystem:

1  Public class c{2      Public void Close () {3         System.out.println ("Close the refrigerator Door"); 4     }5 }

　　Since this three classes are processing related business, that is actually a subsystem of different logical processing modules, access to such subsystems can be accessed through the following appearance, the appearance of the object code as follows:

1  Public classfacade{2     //the object being delegated3     PrivateA A =NewA ();4     Privateb b =NewB ();5     Privatec C =NewC ();6 7     //methods to provide external access8      Public voidmethoda{9          This. A.open ();Ten          This. B.pack (); One          This. C.close (); A     } -  -}

View Code

　　At this point, the implementation of the appearance mode is complete, after the elephant into the refrigerator without a step, the direct call facade method, you can one step, MA Ma no longer worry about the steps are not right ~

Application scenarios for the appearance mode

• When it comes to providing a simple interface for a complex subsystem.
• When there is a large dependency between the client program and the abstract class implementation part.
• When you need to build a hierarchy of subsystems.

You can consider using the appearance mode when you encounter the three cases above.

Above, how to predict the post-style, and listen to tell.

PS: This blog welcome forwarding, but please specify the blog address and author ~

Blog Address: http://www.cnblogs.com/voidy/

Blog: http://voidy.gitcafe.com

<. ))) ≦

The 7th chapter of the design pattern-appearance mode (Java implementation)