Design Mode Study Notes-Facade Mode

Before model learning

What is the design model: when we design the program, we gradually formed some typical problems and solutions, which is the software model; each mode describes a problem that often occurs in our program design and the solution to the problem. When we encounter the problem described by the mode, the corresponding solution can be used to solve the problem. This is the design mode.

A design pattern is an abstract thing. It is not learned but used. Maybe you don't know any pattern at all, and you don't consider any pattern, but write the best code, even from the perspective of "pattern experts", they are all the best designs and have to say "best pattern practices". This is because you have accumulated a lot of practical experience, knowing "where to write code" is a design pattern.

Some people say: "If the level is not reached, you can learn it in vain. If the level is reached, you can do it yourself ". It is true that the mode is well-developed and may still not be able to write good code, let alone design a good framework. OOP understanding and practical experience reach a certain level, and it also means to summarize a lot of good design experience, however, it may not be the case that "no teacher can do anything", or you can say that, on the basis of level and experience, it is time for the system to learn the "mode, it is helpful to learn the experts' summary and verify your own shortcomings.

This series of design patterns learning notes is actually a Learning Record for the book "Java and patterns.

Facade mode definition

External communication with a sub-system must be performed through a unified Facade object, which is the Facade mode.

The facade mode provides a high-level interface to make subsystems easier to use.

Note:The facade mode does not add new behaviors to the system, that is, the facade object does not have functions not available in the subsystem.

Facade mode structure

Structure chart

Roles involved

(1) Facade role: the client can call this role method. This role is aware of the functions and responsibilities of the relevant (one or more) sub-systems. Under normal circumstances, this role delegates all requests sent from the client to the corresponding subsystem.

(2) 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. The subsystem does not know the existence of the facade. For the subsystem, the facade is just another client.

<喎?http: www.bkjia.com kf ware vc " target="_blank" class="keylink"> Signature + PGJyPgo8L3A + signature/2jwvcD4KPHA + o6gyo6nX08 + signature/Signature/CoaM8L3A + signature + Signature = "http://www.2cto.com/uploadfile/Collfiles/20140408/20140408093450193.png" alt = "\ ">

Structure chart after using the facade mode:

Learn more

(1) The facade mode, a very simple mode, aims to define a unified access interface. It should be frequently used in daily work. For example, in the process of system development based on the SOA framework, each subsystem must provide interfaces to each other. This interface can be considered as the facade mode.

(2) The facade mode often serves as a proxy object while serving as a facade object. For example, a facade object may be a remote proxy of a subsystem located in another address space. It may also be a proxy protection role to check the caller's permissions. It may be responsible for recording the number of times the subsystem was called, therefore, this role is also the role of intelligent reference proxy; it may also be the role of virtual proxy, especially when the subsystem is loading time and resources.

Structure Pattern Summary

There are seven schema patterns: adapter, decoration, synthesis, proxy, metadata, facade, and bridge.

Summary: