[Cainiao vernacular design pattern series] Bridge pattern-one connection line, two support points

 

When the children are 5 or 6 years old, they are very creative and imaginative. They also like "follow suit". When they see their neighbors buy new toys, they must yell at their parents to buy one. my parents can't afford it. Today, a car and a big house tomorrow are endless. After a few months, the children's house is full of toys.

One day, my parents bought him a set of building blocks to make the children happy. Every day, the house is suspended constantly. I will build a bridge and a car, I was so happy that my parents had been suspended.

It seems that today's big people already know the charm of the combination! The children developed their thinking from the combination and enjoyed it.

Today, the bridge model is a combination of technologies to provide you with a beautiful solution to solve subclass expansion.

The implementation of the bridge mode is very simple, that is, through the combination of abstract and concrete decoupling.

Bridge ModeCodeBut its oo thoughts are rich and many things can be mined.

First, let's talk about decoupling.DecouplingBy adding a layer to the two aspects of direct dependency, it becomes indirect dependency and supports dynamic behavior. this method will introduce another very important idea for interface programming. by introducing an interface layer, the "abstract" and "concrete" that cannot be separated are not directly dependent.

next, explain why interface-Oriented Programming , that is to say, the specific content should depend on the abstract, and the abstract should not depend on the specific content. when I first joined the company, the supervisor asked us to familiarize ourselves with the structure of the main products of the Department. At that time, there was a headache and a lot of interfaces. I don't know where to start. after that, I went into the interface and did not know what actually was executed and how to implement it. only when you run the Program and follow up step by step can you understand which methods were called, but this time it is easier to get down to details, lack of overall understanding of the framework. the idea at that time was so complicated. Why can I suffer from defining so many interfaces.

I think this process has been developed by many beginners. now I want to answer why you need to implement interface-Oriented Programming: decoupling or decoupling . that's why we need to decouple. why is low coupling and high cohesion so important that we often hear people say "decoupling" on the left and "decoupling" on the right to measure your design and product quality. the purpose of decoupling is to isolate (nonsense, not mentioned ). the purpose of isolation is to better encapsulate . I think software development is a process that adapts to changing needs. how to effectively adapt to the ever-changing demand era is encapsulation. . encapsulation is like a zoom mirror, which can reduce a change infinitely, so that the outside world does not feel that you have changed. the ultimate goal of decoupling is to effectively encapsulate changes and resist changes in demand. the implication of this sentence is that we should not decouple everything. only the areas that are easy to change need to be decoupled . the stability is not decoupled. otherwise, it is easy to over-design. in fact, there is no completely decoupled software. A general definition of an abstract interface implementor decouples the relationship between the aggregate action and concreteimplementor. however, the resulting merge action depends on implementor, which is also called coupling. the reason is that the interface is a kind of contract, which is stable and not changeable. The specific implementation is easy to change. if all interfaces need to be changed, it indicates that the interface definition you abstracted has a problem. Otherwise, no matter what mode you use gof, it cannot solve your problem well, it is exaggerated that the entire system cannot effectively encapsulate changes, which is very fragile and difficult to expand. (Fortunately, we can generally abstract stable interfaces. The degree of stability lies in your design experience and knowledge about the field.)

Then, let's go over it.Encapsulation. Encapsulation is one of the three concepts of OOP. Do not think that you have really understood these three concepts, and do not think that you have really integrated OOP ideas. in fact, most of us are not clear, and we don't know enough about it. (M2, here is just my understanding. You can add it ). at first, I thought the encapsulation was easy to understand. I privatized the members and prevented them from accessing the outside. Isn't it encapsulation. in fact, this is far from the case. A property encapsulates the field, a function encapsulates the implementation details, a class encapsulates the responsibilities, and so on... these are packages with different fineness. the real meaning may be hidden deeper. (encapsulation used to resist changes ??)

Continue,Bridge embodies a single Responsibility Principle. The reason why the bridge mode can be used and the combination method can be used is that there are multiple changes in this class. SRP: for a class, there should be only one reason for its change.

Lu Zhenyu gave a story about easy-to-understand crayons and brushes. the reason for the expansion of the crayons subclass is that the responsibility of the crayons is not uniform, and the size and color of the crayons vary in different directions. the design of the brush effectively encapsulates the two change points on different objects. single responsibility, and better understanding of implementation.

Finally,Combination Principle of priorityThe importance of this benefit should not be discussed. If this consensus has not been reached, this articleArticleEven if it is white.

Finally, of course, hereOCP principles are also indispensable. (What About the LSP principle? I personally think this is mainly used when designing a language. The other is used to measure whether two classes have an inheritance relationship, for example, because an ellipse and a circle violate the LSP principle, the circle cannot inherit from the ellipse)

Mode Comparison:

Compared with the Strategy Mode, strategy changes on a single pivot and the subject logic remains unchanged.

Compared with the decorator mode, both of them can effectively solve the problem of subclass expansion, but the two are completely different in terms of structure and application. the core of decorator lies in mutual decoration, which is reflected in the expansion of a certain function (note"A function"This word reflects the difference between another mode, which will be discussed later when it comes to decorator ). the effects of N decorative classes are not only N * n combinations. N * n, n * n are infinitely possible. The combination of N * n and N * n is conceptually infinitely large (the effect of infinite decoration ). strategy only uses M * n to replace m + n. Its combination method is limited. The structure of classes determines the number of their combination methods and their adaptation scenarios.

References:

• Li Jianzhong, webcast Design Pattern Series

• Min Hong, Java and mode, e-Industry Press

• Lu Zhenyu, design patterns-the story of crayons and brushes

• Differences Between idior, bridge strategy and state

I forgot the most recommendable book: <Agile Software Development> Uncle Bob