proxy pattern
Proxy proxy mode is a structural typeDesign pattern, the main problem to be solved is the problem caused by directly accessing objects. For example, the object to be accessed is on a remote machine. In an object-oriented system, direct access to some objects will bring a lot of trouble to users or system structure for some reasons (such as high object creation cost, or some operations need security control, or need out of process access). We can add an access layer to this object when accessing this object. As shown below:
For example, C and a are not on the same server, and a needs to call C frequently. We can make a proxy class proxy on a and hand over the work of accessing C to the proxy. In this way, for a, it is like directly accessing the object of C. In the development of a, we can focus entirely on the implementation of business.
GOF “design pattern” says: provide a proxy for other objects to control the access of this object.
Structure of proxy mode:
Through the agent mode, the behavior is controlled dynamically as the target object in the form of customer transparency
example
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
class BankAccount def deposit p "store the money" end endclass Proxy attr_accessor :bankAccount def initialize bankAccount @bankAccount = bankAccount end def deposit @bankAccount.deposit end end |
Create a bank account class and then create an agent class. The agent class aggregates the bank account class and provides the same behavior structure. For customers, the agent class is a pseudo account class. When operating on the agent class, it is actually operating on the real bank class.
Conduct control:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
|
class Proxy attr_accessor :bankAccount def initialize bankAccount @bankAccount = bankAccount end def deposit check_something @bankAccount.deposit end def check_something #do some checking code end end |
In this way, we can add control code while calling the target object, but all this is presented to the customer in a transparent way. For the customer, it is the same as calling the ordinary bankaccount object method
|
1
2
3
4
|
bankAccount = BankAccount.newbankAccount.depositproxy = Proxy.new bankAccountproxy.deposit |
Key points of proxy mode:
1. Adding an indirect layer is a common solution to many responsible problems in software systems. In object-oriented system, using some objects directly will bring many problems. Proxy object as an indirect layer is a common means to solve this problem.
Proxy mode is often used in our daily work. For example, for the DAL data access layer in the three-tier structure or N-tiers structure, it encapsulates the access to the database. The developers of Bll business layer just call the methods in Dal to obtain data.
For another example, I looked at AOP and remoting some time ago. For access across application domains, a transparent proxy (transparent proxy) should be provided for the client application. The client actually accesses the actual type object by accessing the proxy.
2. The implementation methods and granularity of specific proxy design patterns vary greatly. Some may control a single object in fine granularity, and some may provide an abstract proxy layer for component modules to proxy objects at the architecture level.
3. Proxy does not necessarily require the consistency of the interface. As long as it can realize indirect control, sometimes it is acceptable to compromise some transparency. For example, in the above example, the proxy type proxyclass and the proxied type longdistanceclass do not need to inherit from the same interface. Just as GOF says in design patterns: provide a proxy for other objects to control the access of this object. From a certain point of view, the proxy type can also control the access of the proxy type.