24-day design model ---- facade model (appearance model), 24-day Design Model

24-day design model ---- facade model (appearance model), 24-day Design Model

Original works of Lin bingwen Evankaka. Reprinted please indicate the source http://blog.csdn.net/evankaka

I. Facade Mode 1. Definition

The GOF Design Pattern describes the Facade Pattern as follows:

Provides a unified interface for a group of interfaces in the subsystem. The Facade mode defines a higher-level interface, making it easier for subsystems to use.

2. Structure

Facade role: the client can call this role method. This role knows the functions and responsibilities of the subsystem. Under normal circumstances, this role delegates all requests sent from the client to the corresponding subsystem.

Subsystem role: You can have one or more subsystems at the same time. Every subsystem is not a separate class, but a collection of classes. Each subsystem can be called directly by the client or by the facade role.

3. Applicability

(1) You do not need to use all the functions of a complex system, and you can create a new class that contains all the rules for accessing the system. If you only need to use some of the functions of the system, the APIS you create for the new class will be much simpler than the APIs of the original system.

(2) You want to encapsulate or hide the original system.

(3) You want to use the functions of the original system and add some new functions.

(4) The cost of writing new classes is less than what everyone learns to use or will need to maintain the original system in the future.

Ii. Example

The following uses shopping in a store as an example. In general, if we want to buy things directly in a store, rather than in a factory that produces products, the store here can be seen as a facade, then the factory is a sub-system. When you need any products, you just need to go to the store to buy them. You don't have to worry about the factory. The store depends on the products you want, select different factories to purchase goods.

Package com. model. facade;/*** a soap class */class Coat {public String toString () {return "Soap ";}} /*** soap manufacturer */public class CoatFactory {/*** manufacturer sells soap */public Coat saleCoat () {return new Coat ();}}

Package com. model. facade;/*** Computer class */class Computer {public String toString () {return "one Computer ";}} /*** Computer manufacturer */public class ComputerFactory {/*** sells computers */public Computer saleComputer () {return new Computer ();}}

Package com. model. facade;/*** Fruit class */class Fruit {public String toString () {return "Fruit box ";}} /*** Fruit manufacturer */public class FruitFactory {/*** Fruit seller */public Fruit saleFruit () {return new Fruit ();}}

The store is coming:

Package com. model. facade;/*** Store, which purchases factory items and then sells them to the customer */public class Store {/*** Store for soap */public Coat saleCoat () {CoatFactory m_CoatFactory = new CoatFactory (); return m_CoatFactory.saleCoat ();}/*** shop sells computers */public Computer saleComputer () {ComputerFactory m_Computer = new ComputerFactory (); return m_Computer.saleComputer ();}/*** Fruit shop */public Fruit saleFruit () {FruitFactory m_FruitFactory = new FruitFactory (); return second ();}}

Customers:

Package com. model. facade;/*** @ author Lin bingwen * @ time 2015.2.10 * facade mode Description */public class Main {public static void main (String [] args) {Store m_Store = new Store (); // buy clothes System. out. println ("customer buys:" + m_Store.saleCoat (); // buy a computer System. out. println ("customer bought:" + m_Store.saleComputer (); // buy fruit System. out. println ("customer bought:" + m_Store.saleFruit ());}}

Result:

Customer bought: Soap
Customer buys: one computer
Customer buys: a box of fruit

Iii. Advantages and Disadvantages 1. Advantages

(1) shield sub-system components from the customer, reduce the number of objects processed by the customer, and make the sub-system easier to use. By introducing the appearance mode, the Customer Code becomes very simple and there are few objects associated with it.

(2) The loose coupling between the subsystem and the customer is realized, so that the component changes of the subsystem do not affect the customer class that calls it. You only need to adjust the appearance class.

(3) reduces compilation dependencies in large software systems and simplifies the porting process between systems on different platforms, because compiling a sub-system generally does not need to compile all other subsystems. Modifications to a sub-system have no impact on other subsystems, and changes in the sub-system do not affect the appearance objects.

(4) it only provides a unified portal for accessing sub-systems and does not affect the direct use of sub-system classes.

2. Disadvantages

(1) The customer's use of the sub-system class cannot be well limited. If too many restrictions are imposed on the customer's access to the sub-system class, the variability and flexibility are reduced.

(2) without introducing abstract appearance classes, adding a new subsystem may need to modify the appearance class or client source code, which violates the "open/closed principle ".

Summary

The Facade design model focuses more on the entire system from the architectural level, rather than the individual class level. In most cases, Facade is an architectural design model. Facade focuses more on simplified interfaces, Adapter mode focuses on conversion interfaces, Bridge Mode focuses on separation of interfaces (abstraction) and its implementation, and Decorator mode focuses on object extension functions on the premise of stable interfaces.

Original works of Lin bingwen Evankaka. Reprinted please indicate the source http://blog.csdn.net/evankaka