1. The principle and realization of the proxy model
Without changing the original class (or called the proxy class), the proxy class is introduced to add functionality to the original class. Under normal circumstances, we let the proxy class and the original class implement the same interface. However, if the original class does not define an interface, and the original class code is not developed and maintained by us. In this case, we can implement the proxy mode by letting the proxy class inherit the method of the original class.
2. Principle and realization of dynamic agent
Static agents need to create a proxy class for each class, and the code in each proxy class is a bit like template-like "duplicate" code, which increases maintenance costs and development costs. For the problems of static proxy, we can solve it through dynamic proxy. We do not write a proxy class for each primitive class in advance, but dynamically create the proxy class corresponding to the original class at runtime, and then replace the original class with the proxy class in the system.
3. Application scenarios of proxy mode
The agent model is often used to develop some non-functional requirements in business systems, such as: monitoring, statistics, authentication, current limiting, transactions, idempotence, and logging. We decouple these additional functions from business functions and put them in the agent class for unified processing, so that programmers only need to focus on business development. In addition, the proxy mode can also be used in application scenarios such as RPC and caching.
Bridge mode
In GoF's "Design Patterns" book, the bridge pattern is defined as: "Decouple abstraction and implementation so that they can be changed independently." In other materials and books, there is another simpler way to understand: " A class has two (or more) dimensions that change independently. We combine these two (or more) dimensions to expand independently."
For the first way of understanding GoF, understanding the two concepts of "abstraction" and "implementation" in the definition is the key to understanding it. The "abstraction" in the definition does not refer to "abstract classes" or "interfaces", but a set of abstracted "class libraries", which only contain skeleton code, and the real business logic needs to be delegated to the "implementation" in the definition "To be done. The "implementation" in the definition is not the "implementation class of the interface", but a set of independent "class libraries". The "abstraction" and "realization" are developed independently and assembled together through the combination of objects. For the second way of understanding, it is very similar to the design principle of "combination is better than inheritance", which replaces inheritance relations with composition relations to avoid exponential explosion of inheritance hierarchy.