Design pattern (ix) Appearance mode facade (structural type)

Design pattern (ix) Appearance mode facade (structural type)

1. Overview

Appearance mode, we use the appearance of packaging, so that the application can only see the appearance of objects, but not to see the details of the object, this will undoubtedly reduce the complexity of the application, and improve the maintainability of the program.
Example 1: A power master switch can control four lights, a fan, an air conditioner and a TV set to start and close. The main power switch can control all of the above electrical equipment, the main power switch is the system's appearance mode design.

2. Questions

In order to reduce the complexity, the system is often divided into a number of subsystems. But how to achieve the minimum of communication and interdependence between the various systems?

3. Solution

appearance Mode : Provides a consistent interface for a set of interfaces in a subsystem, and the facade schema defines a high-level interface that makes this subsystem easier to use. After the appearance role is introduced, the user only needs to interact directly with the appearance role, and the complex relationship between the user and the subsystem is implemented by the appearance role, thus reducing the coupling of the system.

4. Applicability

Use facade mode when encountering the following conditions:
1) When you want to provide a simple interface for a complex subsystem. Subsystems tend to become more complex as they evolve. Most patterns will produce more and smaller classes when used.
This makes the subsystem more reusable and easier to customize the subsystem, but it also brings some usability difficulties to users who do not need to customize the subsystem. Facade can provide a simple default view,
This view is sufficient for most users, and those who need more customization can cross the facade layer.
2) There is a large dependency between the client program and the implementation part of the abstract class. The introduction of facade separates this subsystem from customers and other subsystems, which can improve the independence and portability of subsystems.
3) 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 make them communicate only through facade, simplifying their dependencies.

5. Structure

6. Composition of the build pattern

Appearance role (facade): is the core of the pattern, he is called by the customer client role, know the functions of each subsystem. At the same time, according to the existing requirements of the customer role to subscribe to several functional combinations \
subsystem role (Subsystem classes): Implements the functions of the subsystem and processes tasks assigned by the facade object. For subsystems, the facade and client roles are unknown and do not have any relevant information about the facade; that is, there is no instance pointing to facade.
Customer role (client): Call the facade role to get the appropriate functionality done.

7. Effects

The facade model has some of the following advantages:

1) to the customer shielding subsystem components, reduce the number of objects processed by customers and make the subsystem easier to use. By introducing the appearance pattern, the customer code becomes very simple, with very few objects associated with it. 2) The loosely coupled relationship between the subsystem and the customer is realized, which makes the component changes of the subsystem not affect the customer class that calls it, only the appearance class can be adjusted. 3) reduces compilation dependencies in large software systems and simplifies the porting of systems between different platforms, since compiling a subsystem generally does not require compiling all of the other subsystems. The modification of one subsystem has no effect on other subsystems, and the internal changes of the subsystem do not affect the Appearance object. 4) just provides a unified access subsystem, and does not affect the user directly using the Subsystem class. Disadvantage of Facade mode 1) It is not very good to restrict the use of subsystem classes for customers, and if too many restrictions on the client access subsystem classes are reduced variability and flexibility. 2) without introducing abstract appearance classes, adding new subsystems may require modifying the source code of the Appearance class or client, violating the "open and closed principle".

8. Implement

Examples of our use of switches;

[PHP]View Plain Copy print?

2. <?php
4. /**
6. * Appearance mode
8. *
10. */
12. class Switchfacade
14. {
16. private $_light = null; //Electric bulb
18. private $_ac = null; //Air conditioning
20. private $_fan = null; //fan
22. private $_TV = null; //TV
26. Public function __construct ()
28. {
30. $this->_light = New Light ();
32. $this->_fan = new Fan ();
34. $this->_ac = new Airconditioner ();
36. $this->_TV = new Television ();
38. }
40. /** 
42. * Open the lights at night
44. *
46. */
48. Public function method1 ($isOpen =1) {
50. if ($isOpen = = 1) {
52. $this->_light->on ();
54. $this->_fan->on ();
56. $this->_ac->on ();
58. $this->_tv->on ();
60. }else{
62. $this->_light->off ();
64. $this->_fan->off ();
66. $this->_ac->off ();
68. $this->_tv->off ();
70. }
74. }
76. /** 
78. * Lights are not needed during the day
80. *
82. */
84. Public function Method2 () {
86. if ($isOpen = = 1) {
88. $this->_fan->on ();
90. $this->_ac->on ();
92. $this->_tv->on ();
94. }else{
96. $this->_fan->off ();
98. $this->_ac->off ();
100. $this->_tv->off ();
102. }
104. }
106. }
110. /****************************************** Subsystem Class ************/
112. /**
114. *
116. */
118. Class light
120. {
122. private $_isopen = 0;
124. public function on () {
126. echo ' light is open ', ' <br/> ';
128. $this->_isopen = 1;
130. }
132. public function off () {
134. echo ' light is off ', ' <br/> ';
136. $this->_isopen = 0;
138. }
140. }
144. Class Fan
146. {
148. private $_isopen = 0;
150. public function on () {
152. echo ' Fan is open ', ' <br/> ';
154. $this->_isopen = 1;
156. }
158. public function off () {
160. echo ' Fan is off ', ' <br/> ';
162. $this->_isopen = 0;
164. }
166. }
170. Class Airconditioner
172. {
174. private $_isopen = 0;
176. public function on () {
178. echo ' airconditioner is open ', ' <br/> ';
180. $this->_isopen = 1;
182. }
184. public function off () {
186. echo ' airconditioner is off ', ' <br/> ';
188. $this->_isopen = 0;
190. }
192. }
194. Class Television
196. {
198. private $_isopen = 0;
200. public function on () {
202. Echo ' television is open ', ' <br/> ';
204. $this->_isopen = 1;
206. }
208. public function off () {
210. Echo ' television is off ', ' <br/> ';
212. $this->_isopen = 0;
214. }
216. }
218. /**
220. * Customer Class
222. *
224. */
226. Class Client {
228. Static function open () {
230. $f = new Switchfacade ();
232. $f->method1 (1);
234. }
238. static function Close () {
240. $f = new Switchfacade ();
242. $f->method1 (0);
244. }
246. }
248. Client::open ();

11. With other related modes

1) Abstract Factory mode: An abstract factory can be used with the facade mode to provide an interface that can be used to create subsystem objects in a separate way from a subsystem. Abstract Factory can also be used instead of the facade mode to hide those platform-related classes.
2) Mediation Mode: The similarity between the mediator pattern and the facade pattern is that it abstracts the functionality of some existing classes. However, the purpose of mediator is to abstract the arbitrary communication between colleagues, often concentrating functions that are not part of any single object.
Mediator's colleague object knows the mediator and communicates with it, rather than communicating directly with other homogeneous objects. In contrast, the facade pattern abstracts only the interfaces of subsystem objects, making them easier to use, does not define new functionality, and the subsystem does not know the existence of facade.
Typically, only one facade object is required, so the facade object is usually in singleton mode.
3) Adapter mode:
The adapter pattern is to indirectly convert an interface to another interface through adaptation.
Appearance mode words, its main is to provide a neat and consistent interface to the client.

12. Summary

1) According to the "single responsibility Principle", dividing a system into several subsystems in software is helpful to reduce the complexity of the whole system, a common design goal is to minimize the communication and interdependence between subsystems, and one of the ways to achieve this is to introduce a visual object. It provides a simple and single entry for subsystem access.

2) The appearance mode is also the embodiment of "Dimitri Law", by introducing a new appearance class can reduce the complexity of the original system, the appearance class acts as the "third party" between the customer class and the subsystem class, and reduces the coupling degree between the customer class and the Subsystem class. The appearance pattern is a powerful weapon that implements code refactoring in order to achieve the requirements of "Dimitri Law".

3) The appearance mode requires that the external and internal communication of a subsystem be carried out through a unified appearance object, which separates the client from the internal complexity of the subsystem, so that the client only needs to deal with the appearance object, without having to deal with many objects inside the subsystem.

4) The appearance mode greatly improves the convenience of the client, so that the client does not care about the work details of the subsystem, and can invoke the related function through the appearance role. 5) Do not attempt to add new behavior to the subsystem through the appearance class, it is wrong to add new behavior to the subsystem by inheriting a skin class. The intention of the appearance mode is to provide a centralized and simplified communication channel for the subsystem, instead of adding new behavior to the subsystem, the new behavior should be implemented by modifying the original subsystem class or adding a new subsystem class, which cannot be implemented by the appearance class.

13. Mode expansion

a system has multiple skin classes: in appearance mode, you typically only need one skin class, and this skin class has only one instance, in other words, it is a singleton class. In many cases, in order to conserve system resources, the appearance class is generally designed as a singleton class. Of course, this does not mean that there can be only one appearance class in the whole system, and in one system you can design multiple appearance classes, each of which is responsible for interacting with specific subsystems and providing the appropriate business functions to the user. do not attempt to add new behavior to the subsystem through the Appearance class: It is wrong to add new behavior to the subsystem by inheriting a skin class. The intention of the appearance mode is to provide a centralized and simplified communication channel for the subsystem, instead of adding new behavior to the subsystem, the new behavior should be implemented by modifying the original subsystem class or adding a new subsystem class, which cannot be implemented by the appearance class. appearance mode and Dimitri Law: The Appearance pattern creates a visual object that minimizes the number of partners involved in a subsystem that the client touches, making the interaction between the client and the object within the subsystem replaced by the skin object. The appearance class acts as a "third party" between the customer class and the subsystem class, reduces the coupling between the customer class and the subsystem class, and the appearance pattern is a powerful weapon to realize the Code reconstruction in order to achieve the "Dimitri Law" requirement.

Introduction of abstract appearance classes:

The biggest drawback of the appearance mode is that it violates the "open and close principle", when adding a new subsystem or removing the subsystem needs to modify the appearance class, can solve the problem by introducing the abstract appearance class to some extent, the client program for the abstract appearance class. For new business requirements, do not modify the original appearance class, and corresponding to add a new concrete appearance class, the new concrete appearance class to associate the new subsystem object, and by modifying the configuration file to achieve the purpose of not modifying the source code and replace the appearance class.

Uml:

Design pattern (ix) Appearance mode facade (structural type)