3. Summary of Appearance mode
The appearance class is introduced, and the coupling between the client class and subsystem is relieved. Customer classes do not need to directly manipulate the subsystem, but by the appearance of the class is responsible for processing, for the client is transparent, customer class only need to manipulate the appearance of the class can be, in line with the "Di Fan law." If more than one place needs facade, that is, the appearance can realize the function of sharing, that is, the implementation of reuse, the same call code is only used in the facade to write once, do not need to repeat in multiple calls. If a system module needs to be modified, only need to modify the system module can be, no impact on the client, good maintenance. There is also a potential benefit to the people who use facade, facade save their learning costs, they just need to understand facade, need not go deep into the subsystem, to understand the details of each module, and do not interact with multiple modules, so that the development of simple, learning is easy.
Now the system is bigger, more and more complex, the requirements of the software is also more and more high. In order to improve the reusability of the system, usually a large system is divided into subsystems, and then a subsystem into a number of smaller subsystems, has been divided into a small module, so that the reuse of the subsystem will be strengthened. But this also poses a problem, as the modules increase, and the coupling between objects increases. The appearance mode can solve this problem, by the appearance to each sub-module subsystem processing, the client only needs the operation appearance to be possible.
Typically in a three-tier architecture, it is necessary to consider creating a facade between the layers and layers of the data access layer and the business logic layer, the business logic layer, and the UI layer, which provides a simple structure for complex subsystems, which makes the coupling much less. For example, defining a Skin object in the UI layer, the façade is responsible for processing the subsystem of the application layer, and when the UI layer has a request, it is delegated to the application layer's subsystem through the appearance of the UI layer. It is also possible to define a skin object at the application layer, which is delegated to the module in the data layer to process the data when the application layer requests processing of the data.
1. Appearance Mode Advantages
The main advantages of the appearance mode are as follows:
(1) It shields the subsystem components from the client, reduces the number of objects that the client needs to process, and makes the subsystem easier to use. By introducing the appearance pattern, the client code becomes very simple and the object associated with it is very small, conforming to the "Dimitri Law".
(2) It realizes the loose coupling between the subsystem and the client, which makes the subsystem change does not affect the client that calls it, only needs to adjust the appearance class.
(3) The modification of one subsystem has no effect on other subsystems, and the internal changes of the subsystem will not affect the appearance object.
(4) The Appearance object is responsible for the subsystem processing, if a subsystem has been modified, may only need to modify the appearance of the object can be, good maintainability. If you do not use a skin object, a subsystem is modified, and if more than one client uses this subsystem, these clients are modified and poorly maintained.
(5) Multiple clients can reuse the appearance of facade, good reusability.
(6) In accordance with the multi-use combination less the principle of inheritance.
2. Appearance mode disadvantage
The main drawbacks of the appearance pattern are as follows:
(1) It is not very good to restrict the use of the subsystem class directly by the client, which reduces variability and flexibility if there are too many restrictions on the client Access subsystem classes.
(2) If the design is inappropriate, adding new subsystems may require modifying the source code of the Appearance class, which violates the open and closed principle.
3. Appearance mode applicable scene
(1) You can use the appearance mode when you want to provide a simple portal for accessing a complex set of subsystems.
(2) 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.
(3) In a hierarchical structure, the appearance pattern can be used to define the entrance of each layer in the system, and the layers are not directly related to each other, but the contact is established through the appearance class, and the coupling degree between the layers is reduced.
4. Specific application of the appearance mode
(1) The development of the Mail Business system: The sender only need to send the content, the receiving address told the Post Office, the Post Office system to send processing. The Post Office system acts as a skin role.
(2) system has a homepage or navigation page, but also provides a menu or toolbar, here, home and navigation page, Dish Single and toolbar is appearance role, Through their users can quickly access the subsystem, reducing the complexity of the system.
(3) KTV Song System development: To provide a look to handle the display module, sound module, light module operation.
(4) File Security Transfer Module development: There are three modules, read the file content module, the contents of the file encryption module and write file module. Provides a look for these modules to be processed.
(5) In a three-tier architecture, the UI layer and the business logic layer provide a look, the business logic layer and the data access layer provide a look, which provides a simple structure for complex subsystems.
(6) The appearance of life: to find computer Assembly company Assembly computer, through the intermediary to deal with the sale of the house;
Appearance mode of C + + design mode (iii)