Design Pattern-bridge and Strategy)

They are put together because they are very similar but completely different.

Let's take a look at the bridge mode.

1) if the customer gives a requirement, we implement Class

2) After a few days, the customer said that this stuff requires two algorithms, So we derived A0, A1

3) after a few days, the customer made a request to implement it in different operating systems. Therefore, we derived the following classes: a0a, a0b, A1A, and A1B.

In this way, we need to constantly derive and change

The Bridge Mode solves this problem. Objects and behaviors must be constantly changed. Objects and behavior classes must be separated and evolved independently. The object class contains the variables of the behavior class, in this way, you can freely combine them. The class graph relationships are as follows:

In this example, the extract action and extract actionimp are the abstract interfaces of classes and actions, that is, the base classes. Bridge uses a combination instead of a continuation method to solve the problem. This is in line with the object-oriented idea. It can be combined without inheritance as much as possible, making the code more flexible.

There is an article about bridge very well, http://www.blogjava.net/lijiajia418/archive/2006/09/18/70268.html

In addition, the similarities and differences between bridge and visitor are as follows:

At the beginning, I thought that the two models were almost the same. They separated elements and behaviors, and then evolved and combined independently. But they are quite different.

1) for the bridge mode, the lateral action should contain the pointer of the lateral actionimp; for the visitor, the element does not contain the pointer of the visitor. From this point of view, the elements and actions described by bridge are more cohesive.

2) The structure of bridge makes the behavior of a class relatively independent from that of the class, while visitor makes different implementations of a behavior of the class independent of each other, in addition, vistor behavior does not necessarily belong to the behavior of the object it processes. Bridge is to separate abstract classes from their own behavior implementations. vistor is to separate abstract classes from various external access behaviors.

3) Although the visitor has the idea of separation of elements and behaviors, the most important thing about this mode is the dual-distribution mechanism, which can be used in a way similar to EMP-> accpt (pvisitor) to achieve dual distribution, you can write the code very easily, especially in the loop, without many conditions, which is also its biggest use, however, this is based on the stability of the element class and does not need to be added. If the specific element class is unstable and needs to be added frequently, all the specific visitor classes must be modified, it is not in line with the OCP, but the application scenario of the bridge model is not like this at all. The elements and behaviors to be solved can be evolved separately.

Let's take a look at the strategy mode.

Its definition is also very simple. It defines algorithm clusters and encapsulates them separately so that they can dynamically replace each other, so that users can use different algorithms for implementation. Its Class diagram is very similar to that of bridge.

Similarly, context contains a pointer to the strategy object, so that context can use different policy algorithms, or even sub-classes of context, so that the class diagram is exactly the same as that of bridge.

In fact, all modes can only be divided into class mode and object mode. Class mode uses inheritance While object mode uses delegation, the bridge mode is similar to the Strategy Mode because they all delegate tasks to the specific implementation of another interface.

Now let's take a look at their differences and find out the differences, so that we can really find out the two design patterns. I have referred to some classic descriptions on the Internet:

I. There are some differences between the two in form. By comparing the two structure charts, we can find that in the bridge mode, not only the behavior is changed, but also the merge action can also be changed, the changes between the two are completely independent. They are only linked by the relationship between the role action and implementor. In the policy mode, context changes are not taken into account. Only the algorithm can be replaced. Of course, we have said that context can also be sub-classes, so that they will be the same in the class diagram, however, for strategy, context changes are not the focus of its concern.

2. The most important difference between them is the Red words in strategy. Strategy encapsulates the algorithm so that the algorithm can be dynamically replaced. That is to say, the value of the pointer to the strategy object in context can be dynamically set. Generally, there is a method similar to setstrategy in context, so it is a behavior mode, it describes the changes in behavior. In the bridge mode, the pointer to behavior cannot be changed. It mainly expresses the elements and behaviors in a system that can be changed and combined at will, however, once the combination is complete, it is more about describing the structure of the system, so it is a structure mode. Many implementation modes are similar, but their application scenarios are different. This is the most important part of the design mode. The mode is just an implementation tool.