First, the primer
The facade pattern is very simple design pattern.
Second, definition and structure
Facade mode is also known as the appearance mode. GOF gives the following definition in the "design mode" book: Provides a consistent interface for a set of interfaces in the subsystem, and the FACADE mode defines a high-level interface, which makes this subsystem easier to use.
The subsystem mentioned in the definition refers to the division of the system in order to reduce complexity according to certain rules (such as business, function). There are some classes in the package in the subsystem. When the client is using the subsystem, it may be as challenged as the following figure.
In the above implementation method, the customer is tightly relying on the implementation of the subsystem. The changes in the subsystem are likely to affect the call of the customer class. Moreover, the subsystem is constantly optimized, and the reconstruction of reusable is generated, and more smaller classes are generated. This is to complete a workflow for the customer class using subsystems, and it seems that there is too much interface.
The facade mode is to solve this problem. Look at the picture after using the facade pattern:
This reduces the coupling between the client and subsystem, which increases maintainability.
Obviously, the facade model has three characters:
1) Facade role (FACADE): This is the core of the facade pattern. It is called by the customer role, so it is familiar with the functionality of the subsystem. It is within a reservation of several functional combinations within the customer's role.
2) Subsystem role: The function of the subsystem is realized. For it, the façade role is the same as the customer role, it does not have any façade roles and links.
3) Customer role: Call the Façade role to complete the function you want.
Third, for example
FACADE is a typical application is to perform a database connection. Generally we access the database every time: first get the Connect instance, then open the Connect to get the connection, get a statement, execute the SQL statement for query, get the query result set.
We can extract these steps and package them in a class. This way, each execution database access only needs to pass the necessary parameters to this class.
Interested in implementation in the system you are on.
Fourth, use environment and advantages
"Design Mode" gives the environment of the facade mode:
1) When you want to provide a simple interface for a complex subsystem. The reason has been described above.
2) There is a lot of dependence between the client program and the abstract class's implementation. Introducing FACADE to separate this subsystem from customers and other subsystems, which can improve the independence and portability of the subsystem (mentioned above).
3) When you need to build a hierarchy subsystem, use the FACADE mode to define the entry points in the subsystem in the subsystem. If the subsystem is interdependent, you can make them communications with FACADE, which simplifies the dependence between them.
The following is its advantages:
1) It is to shield the subsystem components of the customer, thus reducing the number of objects handled and makes the subsystem more convenient.
2) It achieves loose coupling relationship between subsystems and customers, while the functional components within the subsystem are often tight coupling. Loose coupling relationship makes the components of the subsystem do not affect its customers. The FACADE mode helps establish a hierarchical system, which also helps to delay the dependency between objects. FACADE mode eliminates complex cyclic dependencies. This is especially important when the client program and subsystem are achieved separately. Reduce compilation dependence in large software systems is critical. When the subsystem class changes, you want to minimize the compilation operation to save time. Using FACADE to reduce compilation dependencies, restrict the re-translation of smaller changes in important systems. The FACADE mode is also conducive to simplifying the transplantation process between the system in different platforms, because compiling a subsystem generally does not need to compile all other subsystems. 3) If the application needs, it does not limit their use subsystem classes. So you can make the customer program to choose between system ease and versatility.
V. Facade mode in Java
Let's think about the facade model and which pattern we have already said? The answer is abstract factory model. Although the two are distinguished in classification, they are all established for the use of the customer program. The difference between the two should be that the facade model is not only convenient for customers, but also hides classes that should not let customers know (these classes are only otherwise other class services for the subsystem).
But the concept of the package provided in the Java language has been able to solve the problem mentioned above. You can put a subsystem in a package, which is to provide the class to the outside to define as public, without the published class, can be designed as non-public.
Therefore, at a certain extent, the facade pattern is basically not used in Java.
Although the standard facade pattern can be used, this idea that provides an intermediate or intermediate method is convenient for the customer program should be worth our practice.
Six, summary
The facade pattern is from the whole, and the feeling of giving me is that it is very helpful for the coarse particles between the two layers, avoiding a large number of fine particle sizes. This is the same as some views in SOA.
The facade pattern is generally introduced. Please correct :)
The facade pattern is from the whole, and the feeling of giving me is that it is very helpful for the coarse particles between the two layers, avoiding a large number of fine particle sizes. This is the same as some views in SOA.
The facade pattern is generally introduced. Please correct :)
