Design Pattern learning-Facade Pattern

Today I will talk about the appearance mode. This mode is actually very simple to understand. Why? In fact, I think we can use four words to describe this model: simplifying the model. This mode is used to provide simplified interfaces. What is a simplified interface? In fact, it is to combine many complex interfaces into a new interface. You may ask, isn't it more complicated to combine many complex interfaces? How can it become simple? Isn't it self-contradictory? Haha, then you are wrong. In fact, the appearance mode is more like a thing: Macro. Let's talk about macro again. Didn't we mention "command macro" in the last command mode? What is the relationship between this mode and macro? Hey, if we call the last "command macro" A "macro in a narrow sense", then the appearance mode is "macro in a broad sense" (it seems increasingly difficult to understand ......).

Don't worry. Let me take it easy to solve the problem of "macro in a broad sense" first. First, in a broad sense, this model has a high degree of universality. That is to say, it is not limited to "bundling" a single type of interface ", it can also perform "centralized sales" for different types of interfaces. The specialty is that the appearance mode can combine interfaces of different subsystems into one interface for users to use, this interface combines many functions so that you do not need to define multiple subsystems and then manually operate these subsystems, instead, you only need to call this integrated interface to complete a lot of functions. Is it simplified?

Let's talk about it in detail. The definition is still necessary:

• Appearance mode:
  Provides a consistent interface for a group of interfaces in the subsystem. The facade mode defines a high-level interface, which makes the subsystem easier to use.
• Applicability:

1. When you want to provide a simple interface for a complex subsystem. Subsystems tend to become more and more complex as they evolve. In most modes, More and smaller classes are generated. This makes subsystems more reusable and easier to customize, but it also brings some difficulties for users who do not need to customize subsystems. Facade can provide a simple default view, which is sufficient for most users, and users who need more customization can bypass the facade layer.
2. CustomerProgramThere is a large dependency between the implementation part of the abstract class. Introducing facade to separate this subsystem from customers and other subsystems can improve the independence and portability of the subsystem.
3. When you need to build a layered sub-system, use the facade mode to define the entry points for each layer of the sub-system. If subsystems are mutually dependent, you can make them communicate only through facade, thus simplifying the dependency between them.

Next, the class diagram:

 

Is this type of graph a bit speechless? Are you confused? Well, don't be intimidated by its appearance. In fact, you only need to care about the top interface. subsystem, that is, the subsystem, does not need to be carefully considered, you only need to know how to call the interface provided by the subsystem. Let's use an example:

Taking driving for example, driving requires a lot of operations and a lot of small details (this is my personal experience when learning a driver's license). Let's simply say: drive the door-> plug the key-> Start the engine-> step on the clutch-> gear-> loosen the clutch-> loosen the handbrake-> refuel door-> turn the steering wheel... (The car is running, haha, but the subsequent steps will depend on you ;)). However, with the development of science and technology, the emergence of fully automated cars (technology really powerful) is now decisive, for such a fully automatic car, it is clear that no one, these operations can only be controlled by the computer, if you want to write such a fully automatic driving program, you only need to insert the key and click the drive button to automatically drive the car (this is convenient for everyone ), how should I write it?

Is it complicated? It doesn't matter. Let's leave the complicated questions to the scientists. We need to know how to use their results. On the assumption that the scientists have encapsulated the complex control functions and become subsystems, for example, the door, gear, engine, clutch, handbrake, and throttle all have their own control methods. Now we only need to write the interface of the car. There are three: permission authentication (the key plug-in, of course, is currently so developed, there may also be other authentication methods), as well as driving, parking, how to do it:

//Vehicle InterfacePublic InterfaceICAR {PublicBool auth ();Public VoidDrive ();Public VoidStop ();}
 

As mentioned above, scientists now provide many control interfaces:

 //  Door Interface  Public   Interface  Icardoor {  Public  Void  Open ();  Public   Void  Close ();}  //  Gear position Interface  Public   Interface  Igears {  Public   Void Setlevel ( Int  Level );}  //  Steering light Interface  Public  Interface  Iturnlight {  //  0 is left, 1 is right      Public   Void Setlight ( Int  Direction );}  //  Speaker Interface  Public   Interface  Ispeaker {  Public   Void  Beep ();} //  Engine Interface  Public   Interface  Iengine {  Public   Void  Open ();  Public   Void  Close ();  Public   Void  Refuel ();}  //  Clutch Interface  Public  Interface  Iclutch {  Public   Void  Press ();  Public   Void  Loose ();}  //  Handbrake Interface  Public   Interface  Ihandbrake {  Public   Void  Pull ();  Public  Void  Loose ();}  //  Throttle Interface  Public   Interface  Iaccelerator {  Public   Void Accelerate ( Int  Level );}  //  Steering wheel  Public   Interface  Iwheel { Public   Void Toleft ( Int  Degree );  Public   Void Toright ( Int  Degree );}  //  Permission authentication (plug-in key, of course, there may also be other authentication methods when technology is so developed ),  Public   Interface  Iauthsystem {  Public  Bool auth ();} 

Since there are already so many interfaces, our automatic system only needs to call these interfaces sequentially:

 Public   Class Autocar Implements  ICAR {icardoor cardoor; igears gears; iturnlight turnlight; ispeaker speaker; iengine engine; iclutch clutch; ihandbrake handbrake; iaccelerator accelerator; iwheel wheel;  Public  Autocar (icardoor cardoor, igears gears, iturnlight turnlight, ispeaker speaker, iengine engine, iclutch clutch, ihandbrake handbrake, iaccelerator accelerator, iwheel wheel, iauthsystem authsystem ){  This . Cardoor = Cardoor; This . Gears = Gears;  This . Turnlight = Turnlight;  This . Speaker = Speaker;  This . Engine = Engine;  This . Clutch = Clutch;  This . Handbrake = Handbrake;  This . Accelerator =Accelerator;  This . Wheel = Wheel;  This . Authsystem = Authsystem ;}  Public   Void  Drive () {cardoor. Close ();  //  The system is used to close the door. People are really lazy ,:)          If (Authsystem. Auth ()) //  Verify Permissions  {Engine. open (); //  Turn on the engine Clutch. Press (); //  Step on Clutch Gears. setlevel (1 ); //  Grade 1 Turnlight. setlight (0 ); //  Turn on the left turn lamp Speaker. Beep (); //  Whistle Clutch. Loose (); //  Release clutch Handbrake. Loose (); // Loose Handbrake Accelerator. Accelerate (1 ); //  Just add a bit. Don't be too violent. Otherwise it will be very violent ,:)  //  Let's hand over the following things to scientists ,:)  }}  Public   Void  Stop ();} 

In this way, you only need to care about the ICAR interface. When you want to go out, you only need to open the door, insert the key, and then press the "Drive" button, then you don't need to worry about anything. how comfortable it will be. In fact, you have to thank the appearance model for all this, the appearance mode is to provide a very friendly appearance to users (who do not like it), so that users do not need to care about its internal implementation details, this frees users from heavy work.

What is the appearance mode above? Isn't it that simple to aggregate a bunch of classes and then aggregate the methods of different classes into one method? Yes, that's easy! That's easy! I think now you should figure out why I call the appearance model a macro in a broad sense. If you don't believe it, read the above.CodeIsn't the drive () method in the car class a typical macro? If you still don't know, please study Office Word in depth ,:)

Well, this mode is here, but by the way, there are several other modes: the modifier mode and the adapter mode. Do these three modes have something in common? Yes, they share the same thing: Re-encapsulate interfaces. The modifier mode dynamically adds new responsibilities to the interface of the modifier, And the adapter mode converts the interface of the adapter into a new interface, the appearance mode creates new interfaces by combining multiple system interfaces. Each mode has its own unique effect, depending on how you use it.