Design Mode series-Bridge Mode

ArticleDirectory

• I. Review of the previous Article
• Ii. Summary
• Iii. Outline
• Iv. features and application scenarios of the Bridge Mode
• 5. Classic Implementation of the Bridge Mode
• 6. Other bridging schemes
• VII. Summary of the use of the Bridge Mode
• 8. Series progress
• IX. next announcement

I. Review of the previous Article

In the previous article, we talked about common adapter modes and analyzed the Common Use Cases of adapters:

1. When using third-party class libraries or third-party APIs, we use adapter conversion to meet the needs of existing systems.

2. When our old system is integrated with the new system, we find that the data of the old system cannot meet the requirements of the new system. At this time, we may need an adapter to complete the call request.

3. Data is synchronized between different databases. (Here I only analyzeProgramFor implementation. There are many other methods [Database Synchronization]).

The differences between object adapters and class adapters are described as follows:

Object Adapter: Not through inheritance, but through object combination. As long as we have learned the OO design principles, we know that combination is a recommended method than inheritance.

Class adapter: It is implemented through inheritance to encapsulate the methods of the old system. During the conversion process between the adapters, the Object Adapter can undoubtedly be completed, but the dependency increases, and

The flexibility of expansion may be difficult to control through inheritance.

In addition, C # does not support multi-inheritance, which limits our inheritance policies. The object combination method does not have too many restrictions.

In the previous article, we also talked about switching between adapters, but we didn't provide an example.Code:

The conversion between the adapters is provided here. Sometimes, we find that the two adapters also need to be configured accordingly, for example, the query interface of the above database and XML file, for example, sometimes

You need to convert the data in the XML file to the database, or save the data in the database as XML. In this case, you need to define an object to adapt the corresponding adapters.

For the above description, the core part of the code is as follows:

Query service of the old system

Public interface IQUERY
{
Object Query ();
}

Public class dbquery: IQUERY
{
Public object query ()
{
Throw new notimplementedexception ();
}
}

Public class xmlquery: IQUERY
{
Public object query ()
{
Throw new notimplementedexception ();
}
}

Persistence service of the old system:

Public interface isave
{
Bool save (Object OBJ );
}

Public class xmlsave: isave
{
Public bool save (Object OBJ)
{
Throw new notimplementedexception ();
}
}

Public class dbsave: isave
{
Public bool save (Object OBJ)
{
Throw new notimplementedexception ();
}
}

New system adapter persistence Interface

Public interface ipersistence
{
Bool persistence (Object OBJ );
}

Public class xmlpersistenceadapter: ipersistence
{
Xmlsave save = new xmlsave ();

Public bool persistence (Object OBJ)
{
Return save. Save (OBJ );
}
}

Public class dbpersistenceadapter: ipersistence
{
Dbsave save = new dbsave ();

Public bool persistence (Object OBJ)
{
Return save. Save (OBJ );
}
}

New system query service adapter:

Public interface iselect
{
Object getlist ();
}

Public class xmlqueryadapter: iselect
{
Private xmlquery query = new xmlquery ();
Public object getlist ()
{
Return query. Query ();
}
}

Public class dbqueryadapter: iselect
{
Private dbquery query = new dbquery ();
Public object getlist ()
{
Return query. Query ();
}
}

Conversion between adapters:

Public interface iadaptertoadapter
{
Object getdata ();

Bool savedata ();
}

General transfer plan:

Public class convertadapter: iadaptertoadapter
{
Private dictionary <string, adaptersetting> Settings = new dictionary <string, adaptersetting> ();
Public convertadapter ()
{
// Read the ing relationship of the adapter node to be converted from the configuration file and configure the method to be called
Settings. Add ("", new adaptersetting ());
}

Public object getdata ()
{
Return settings [""]. adaptername. Query ();
}

Public bool savedata ()
{
Return settings [""]. toadaptername. Persistence (this. getdata ());
}
}

In this way, you can complete the basic configuration change service. Of course, I have not implemented the complete code in it. Here I just give you some ideas. If you have good ideas or suggestions, please leave a message and reply. Thank you!

Ii. Summary

This article will describe another important mode in the structural mode-the bridge mode. The main feature of this mode is to solve the multi-direction dependency of the factors that may change an object. Sometimes an object

There are many reasons for this object to change. At this time, we can consider the specific implementation of dependencies and promote them to dependency abstraction to achieve low coupling between objects and change factors, improve system maintainability and scalability. Besides

Users may not know whether a factor has changed or other possible situations. Of course, the bridge mode is also a hard-to-understand mode in the structural mode, which may be used less in our project. However

A complex object. When the state of this object changes due to multiple factors, we can consider using the Bridge Mode to abstract these factors, let this object depend on these abstract factors, not the specific cause

So that you can adapt to changes.

Let's look at a possible scenario. We now have an underlying Orm. Now we only support cud operations, but not query services. At this time, we want to add a query service, so what should we do? Upload

We may implement it through inheritance. At this time, we may do the following. At present, we have provided SQL and Oracle database support for this Orm.

Through the above, when we add the query service and cache service, we must

The existing persistence service is extended through inheritance, and a cache orm and an orm of the query scheme are extended. If we find that we still need to expand the existing service, we also need to do it through inheritance. This is

What a terrible thing is that after a factor that causes a change, we need to extend all classes at the upper level for inheritance. This is a multiplication operation, I don't think I need to explain more. You know that !, So this

The appearance of the Bridge Mode solves this problem well. Let's look at the class diagram of the Bridge Mode:

The purpose of the bridge mode is to solve such a scenario. The above abstracts the changing factors, and then the specific objects reference the changing factors through combination or attribute injection, this dependency is only dependent on factors.

Abstract: At this time, we will not modify the complex objects in the user program because we change the implementation of specific factors. This satisfies the requirements of the design pattern: separating the abstract part from the implementation part so that they can all change independently.

Iii. Outline

A. Review in the previous article.

B. Summary.

C. Outline of this article.

D. features and application scenarios of the bridge mode.

E. Classic Implementation of the bridge mode.

F. Other solutions in the bridge mode.

G. Summary of the usage of the bridge mode.

H. Series progress.

I. Coming soon.

Iv. Features of the Bridge Mode and application scenarios 4.1. Features of the Bridge Mode

The main purpose of the bridge mode is to abstract the changing factors of an object, not to satisfy the changes of this factor through class inheritance, but to rely on the abstraction of factors through object combinations, in this way, when the Dependent Factors

But we do not need to change the specific implementation of the object, because our object is dependent on the abstract, rather than the specific implementation.

In addition, with such dependency abstraction, it is possible to share multiple objects with such factors. If we are using sharing specific factors, when we change this factor, we must

All objects using this factor are modified accordingly. What if all objects referencing this change factor depend on abstraction rather than concrete dependencies? This also provides variability for our sharing.

4.2 scenarios of Bridge Mode

1. When an object has multiple changing factors, the specific implementation of the dependency is abstracted to the dependency abstraction.

2. When a change factor is shared among multiple objects. We can abstract this change factor and then implement these different change factors.

3. When we expect that multiple change factors of an object can be dynamically changed without affecting the use of the customer's program.

It is indeed difficult to grasp how to apply the bridge mode in a project, because we may also encounter such problems in a specific project, there may be multiple dimensional factors. When an object changes, we can

Consider using the Bridge Mode to complete the design implementation.

5. Classic Implementation of the Bridge Mode

We have discussed so much above. Let's give a classic implementation solution of the bridge mode. Otherwise, we may not be very clear about the implementation of the specific code. How can we achieve a solution that meets the Bridge Mode?

Case?

The following is an example of ORM extension to illustrate the feasibility, advantages, and disadvantages of this solution. The specific code is as follows:

1. First, we will provide an abstract interface. Then we will give the final orm interface of the orm:

Public interface Iorm
{
Isave save
{
Get;
Set;
}

Idelete Delete
{
Get;
Set;
}

Icreate create
{
Get;
Set;
}

Icache Cache
{
Get;
Set;
}

IQUERY Query
{
Get;
Set;
}

Void test ();

}

Abstract Interface Definition of change factors of specific objects

Public interface icreate
{
Bool create (Object O );
}

Public interface isave
{
Bool save (Object O );
}

Public interface idelete
{
Int Delete (int id );
}

Specific implementation scheme of the ORM class:

public class ORM: Iorm
{< br> Public isave save
{< br> Get
{< br> throw new notimplementedexception ();
}< br> set
{< br> throw new notimplementedexception ();
}< BR >}

Public idelete Delete
{< br> Get
{< br> throw new notimplementedexception ();
}< br> set
{< br> throw new notimplementedexception ();
}< BR >}

Public icreate create
{< br> Get
{< br> throw new notimplementedexception ();
}< br> set
{< br> throw new notimplementedexception ();
}< BR >}

Public icache cache
{< br> Get
{< br> throw new notimplementedexception ();
}< br> set
{< br> throw new notimplementedexception ();
}< BR >}

Public IQUERY query
{< br> Get
{< br> throw new notimplementedexception ();
}< br> set
{< br> throw new notimplementedexception ();
}< BR >}

Public void test ()
{
/// Test the cache object!
This. cache. cache (new object ());
}
}

The specific call is performed through an interface. Therefore, we provide several simple implementation classes for variable factors.

Public class Delete: idelete
{
Public int Delete (int id)
{
Return 0;
}
}

Public class create: icreate
{

Public bool create (Object O)
{
Return true;
}
}

Let's take a look at the specific call code:

Public class factory
{
Public static t create <t> () where T: Class, new ()
{
T target = new T ();

Return target;
}
}

Class Program
{
Static void main (string [] ARGs)
{
Iorm ORM = New ORM ();
Orm. Create = factory. Create <create> ();
Orm. cache = factory. Create <cache> ();
Orm. Test ();
}
}

You may not understand the above Implementation ideas, so I will post the relationship between the change factors and specific objects.

We assume that there are so many changing factors that will affect the internal behavior of the abstract class. We use abstract forms to decouple the relationship between the abstract class and the changing factor.

To achieve independent changes on both sides.

By abstracting every change factor, we let the abstract class dependencies and interfaces, and then inject them to the real through the method of property injection or the method of constructing function injection.

The interior of the specific class of this abstract class. To complete the initialization of the composite object.

Let's take a look at the final handling situation as follows:

Here we use constructor injection or attribute injection to add the specific change factors to be used.

To complete all the functions of the object.

6. Other bridging schemes

The above shows the classic bridge mode. Can we have an improved solution? Can we discuss it based on some of the previous model experiences? The answer is yes. We can use a configuration.

In the form of a file to dynamically inject the specific implementation content into the bridge mode, let's take a look at the description of the graphic words to illustrate the implementation ideas I have provided here.

I will not post the specific implementation code here. The specific implementation code will be provided at the beginning of the next article. Due to the limited length of this article, the content of this section will be discussed in the next article, I hope you will forgive me.

VII. Summary of the use of the Bridge Mode

Through the simple description above, we know that the bridge mode is mainly used to solve the problem that the changing factors of multiple dimensions of an object are too fast and difficult to control, by abstracting the changing factors of each dimension,

Then, we only need to rely on abstraction for our objects. We don't care about the specific implementation calls. Through object combination, we can combine the desired objects. Undoubtedly, this is a very flexible principle that meets the design pattern.

Abstract and implementation separation, so that their respective changes are not affected by the other party. In addition, we also talked about several typical scenarios using the bridge mode. Now we have such problems in our actual projects.

The bridge mode provides a good reference for the system to adapt to changes in multiple dimensions. It is especially suitable for the development process of the underlying framework, changes that adapt to different factors

Change. Of course, the depth and direction of each person's understanding of the model are different. Due to my limited level, if you have any errors, please give me more advice. If you have good suggestions and comments, please leave a message, I will take a closer look. Thank you for your support!

8. Series progress

Creation type

1. Design Mode of system architecture skills-one-piece Mode

2. Design Mode of system architecture skills-factory Mode

3. Design Mode of system architecture skills-Abstract Factory Mode

4. Design Mode of system architecture skills-creator Mode

5. Design Mode of system architecture skills-prototype mode

Structural

1. Design Mode of system architecture skills-Combination Mode

2. Design Mode of system architecture skills-appearance Mode

3. Design Mode of system architecture skills-adapter Mode

4. Design Mode of system architecture skills-Bridge Mode

5. Design Mode of system architecture skills-decoration Mode

6. Design Mode of system architecture skills-enjoy the Yuan Model

7. Design Mode of system architecture skills-Agent Mode

Behavior Type

1. Design Mode of system architecture skills-command mode

2. Design Mode of system architecture skills-Observer Mode

3. Design Mode of system architecture skills-Strategy Mode

4. Design Mode of system architecture skills-responsibility Mode

5. Design Mode of system architecture skills-template Mode

6. Design Mode of system architecture skills-intermediary Mode

7. Design Mode of system architecture skills-interpreter Mode

IX. next announcement

In the next article, we will begin to talk about the decoration mode in the structural mode. This mode is also a common class, as if we wear a dress for an existing class, or a shell is packed out, which is an interesting model. We usually

In the process of game development, it is estimated that this mode will be used more often. We will introduce this mode in the next article. Please continue to support me! Thank you! Your support is my motivation !.