Review design pattern (2)-Bridge pattern (BRIDGE)

I. Talking about trees

Basically everyone knows the concept of tree.

People who study the essence of. NET will know that. Net has an object tree.

People who learn ASP. NET will surely know that there is a control tree on the web.

Even college students who have only studied data structures to take exams will be aware of the concept of tree.

2. Extend requirements into a tree

Here is an example of Photoshop, which we use most frequently.

In Photoshop, there are many graphical tools, such as stars, such as squares, and circles.

In Photoshop, there are many colors for us to choose.

The red stars and the green stars are generated. Red Square, green square, and so on.

Look at the generated tree:

Now there are three types of images and three colors, so we can declare a total of nine classes. Of course, we are not the secondary parent class in the intermediate process.

If we have 18 images and 12 colors, we need to write 18*12 classes, and then add 12 color classes and a total parent class, in total, we need 12*18 + 12 + 1 = 229 classes.

Let's remember this number.

I hope you don't want to talk to me about it. We can write the color into color and then input it dynamically. We assume that there is no color attribute, but we need to implement it ourselves.

3. Object explosion

I have mentioned this word in two design patterns.

I used this word in <Review design mode (I)-share mode>.

Of course, the explosion here is not mentioned aboveArticleIs so horrible.

But we should also improve the pursuit of perfection.

Then let's start to find a solution.

4. Multi-inheritance?

The first thing I think of when I learn C ++ is multi-inheritance.

It is no longer appropriate to describe this model with multiple inheritance. Declare 18 graphics classes, then declare 12 color classes, and then use the specific graphics class to inherit from multiple classes.

Let's take a look at this illustration:

The intricate lines may seem messy, but I think everyone should understand this.

It is easy to understand, but at this time we will look at the number of this class:

Color 12 + color parent class 1 + graphics 18 + graphics parent class 1 + 12*18, this number seems bigger than the number we used before.

Maybe I will argue for him that he sacrificed space in exchange for readability, but poor C # does not support multi-inheritance?

5. Why is multi-inheritance abandoned?

1. in practice, B inherits a and the method is rewritten. c inherits a and the method is rewritten. At this time, d inherits B and c, so is it B's method or C's method?

2. From the object-oriented perspective, each class should have only one parent class, just like saying that one person can only have one parent class.

But multi-inheritance, after all, is easier for us to understand, just like the color and image in the segment.

Abandoning multi-inheritance begins with Java. How do they solve the problem of multi-inheritance from history?

Let's explore the answer in the Java camp.

6. go deep into the Java camp and find the answer

Method 1: replace inheritance with Interfaces. I am not very interested in this. I used to know about it. I want to know something else.

Method 2: in fact, when we use inheritance, there is always a primary inheritance point and a secondary inheritance point. Then we should distinguish the Primary and Secondary inheritance points, then inherit the primary inheritance points, and then use AOP to solve the problem of secondary inheritance points.

VII. AOP + OOP = Complete OOP

AOP, also known as Aspect-Oriented Programming. Most of the design patterns are engaged in the relationship between interfaces and the external, and seldom go deep into the class to solve the problem. AOP solves this problem.

For example, we often need to record logs when creating projects, so this log is often distributed in various classes in a flat manner, however, this log function is not essentially related to the core functions of this category, which violates the single responsibility principle of the object.CodeScattered in all corners, which is not easy to maintain.

In fact, AOP uses a "cross-cutting" technology, which goes deep into the object, writes the functions that affect multiple classes into a module, and injects them into each class. This separates functions, which are often used for secondary inheritance points such as log management and security control.

However, I searched the internet and Microsoft officially did not provide the AOP framework technology, but all of them were sub-implementation frameworks and there were no widely used standards such as Java spring.

8. Return to the next level

Two keywords of spring: Control inversion, dependency injection.

Since we cannot rely on injection, we can inject it normally.

So much nonsense, let's proceed to the question: Bridging Mode. Let's take a simple look at the structure:

Before explaining this, let's take a look at the meaning of the Bridge Mode: separating the abstract part from the implementation part so that they can change each other.

9. Code Evolution

Let me explain the general idea of this model first.

The above example is used to explain. In the bridging mode, we should extract all the changeable points and then combine them into a stable part. Let's look at the code first.

 Class  Program { Static void Main ( String [] ARGs ){ Photoshop PS = New  Photoshop ( New  Redcolor (), New  Star (); PS. Draw ();}} Interface Icolor {} Class  Redcolor : Icolor {} Class  Bluecolor : Icolor {} Class  Yellowcolor : Icolor {} Interface  Igraphics {} Class  Rectangle :Igraphics {} Class  Star : Igraphics {} Class  Round : Igraphics {} Class  Photoshop { Icolor Color; Igraphics Graphics; Public Photoshop ( Icolor C, Igraphics G ){ This . Color = C; This . Graphics = g ;} Public void Draw (){ Console . Writeline (color. GetType (). tostring ()); Console . Writeline (graphics. GetType (). tostring ());}}

The structure at this time should be like this:

In this case, let's calculate the total number of classes:

12 color classes + 18 graphics classes + 1 our graphics = 31 classes. Is it rare?

10. Exploring and tracing

There is no way in the world. If there are more people, the road will become.

In fact, there is no mode in the world, but the principle is summarized, and it becomes a mode.

Patterns can be derived, while principles are relatively stable. Let's explore principles from this pattern.

At the beginning of the article, what do we think? The third principle of object orientation inherits the first one in the multi-state encapsulation: inheritance. This causes an object explosion. The combination solves this problem.

I still remember the difference between an abstract class and an interface.

Let's start with this interview question:

1. interfaces are behavior contracts, while abstract classes are feature abstractions. One is can do and the other is.

2. object-oriented design principle: combination is better than inheritance.

Well, let's look at the second point. Why do we say that a combination is better than inheritance, not a combination instead of inheritance?

Let's continue to look down.

11. Keep improving

Combination is better than inheritance, rather than composition replaces inheritance.

The above Code requires more than color and shape, so I have to write a lot of attributes, which is troublesome.

And more importantly, if I have such a requirement, I now have 12 colors and 3 shapes, which are square, round, and star. There are two pen types, pencil and crayons. However, my pencil now only corresponds to square and stars, and the crayons only correspond to circles and stars. That is to say there is no circular pencil or square crayon. In this case, isn't my combination a waste? And the customer may be wrong in combination?

Yes. Do not consider combinations. Repeat what I love to say: the mode is for change, not for mode. We just need to pull out the change point!

In this case, we should write a stable department. There are two options:

Or use the color as the parent class. This is our personal choice.

In this case, we suppose there are many classes, but we only have a few choices. Is there even fewer classes?

12. There is a capability called trade-offs.

This is what I saw in <return of the Javascript King>. The original text is used for HTML's compliance with web standards.

Here I would like to say that it is not difficult to understand the bridge mode, but to apply it. It's hard for us to extract this change point, but keep our stability point.

This is the ability of the designer to choose!

13. Take one against three -- the factory is still not a factory

I believe everyone is familiar with the factory model.

Remove the ugly if-Else and use the factory to independently become a class.

To cope with database changes, use abstract factory + reflection + web. config to deal with different data access layers.

Factory + reflection should be used for different verification methods.

This almost became a common feature of all layers of petshop. But do we really need this in our project?

The first reason is that if-else is ugly, because once we introduce new logical conditions, we need to modify the source code and recompile it.

Then there are databases and verification methods. I think that few companies actually modify the database and the verification methods of the products they are used.

If so, that is to say, these are fixed, do we still need to use the factory in a pattern for the sake of model?

14. Summary of bridging

Bridge pattrern: separates abstract parts from implementation parts so that they can all change independently.

The article is over. Turn off the lights and go to bed. Hope you can give me more advice!

I have already published a document, but I think the bag article is 4.1 today. I wish you a happy New Year!