Design Mode learning: adapter Mode

The adapter mode is to convert an interface of a class to another interface that the customer wants, so that those classes that cannot work together due to incompatibility of the interface can work together. 

I don't know if you have used the adapter mode in daily coding, but the working mode of the adapter is very common in our life. This article uses the oldest but most representative example to explain. Now there is an electrical appliance worth 1000 yuan working under a 3-hole socket, but the user only has a 2-hole socket, obviously this electrical appliance is useless. We useCodeSimulate this process.

Analog appliances:

 Analog Electric Appliance 


   Public ClassElectric Appliance
{
Public VoidPlay the video in a three-hole outlet (StringFirewire,StringGround,StringZero Line)
{
Console. Write ("Playing music normally ...... \ N");
}
} 

User-expected interfaces:

User expectation Interface


   Public InterfaceUser expectation Interface
{
VoidPlay in a two-hole outlet (StringFirewire,StringGround );
}
 

 

Purchasing an electric appliance with the same function that works under two-hole Sockets for 1000 yuan can meet the user's requirements, but the cost is obviously too high. The user only has a plug-in specification that is not suitable, we only need to spend a dozen dollars to buy a socket converter for conversion.

 Code 

   Public     Class  Adapted electrical appliances: electrical appliances, user expectation Interface
{
  Public     Void  Working under two-hole socket (  String  Firewire,  String  Ground)
{
  String  Zero Line  =    ""  ;
  This  Work under three-hole socket (Firewire, ground wire, zero line );
}
} 

 

Now let's try again. The user should be satisfied:

 Code 


   Static VoidMain (String[] ARGs)
{
The user expects to interface the radio= NewAdapted electrical appliance ();
Radio. Play under two-hole socket ("Firewire","Ground Line");
Console. Read ();
} 

 

The above technique may have been used unconsciously in your usual coding. This is the "adapter mode" mentioned in gof23. Let's take a look at the standard UML diagram of the adapter mode:

 

The relationship between the UML diagram and the role in the above electrical code is as follows:
Taget => user expectation Interface
Adapter => electrical appliance after adaptation
Adaptee => Electrical Appliance
Note: I used "adapted appliances" here, instead of simply using "adapters" in many tutorials, as I found from my discussions last Friday, many people think that the "adapter" is equivalent to the "transformer" or "plug-in converter" in our daily life without advance preparation. They think that it should only have the voltage or plug-in conversion function, instead of playing the video, the literal translation of words can easily mislead those who have not learned the "adapter mode". gof23's conversion principle is similar to the working principle of the adapter, in fact, there is no converter, and we will continue to understand it in terms of its intention and the class diagram.

Now let's repeat the entire process of solving the electrical problem. First, there is a ready-made electrical appliance at hand. However, his work style is different from what the user expects. We cannot modify the electric appliance at will, to maximize the use of resources at hand, we only need to change the way it works to make it consistent with what the user expects. In the code, we use the adapter mode to reuse the electrical appliance class so that the electrical appliance that cannot work can work in the environment that the user expects.

Now we are going deeper, we have met the requirements of users, but we are looking at our code, according to the above inheritance relationship, in addition to implementing the "user-expectation interface", the "adapted electrical appliance" also has all the functions of "electrical appliance", which apparently violates the "single principle ", according to the "7 Principles" we mentioned earlier, we should use "Combination" instead of "inheritance" to reduce the coupling between objects.
In fact, two structures are mentioned for this pattern in gof23. One is "class adapter", which is the structure we mentioned above, and the other is "Object Adapter ". The structure of "Object Adapter" is as follows:

The combination of object adapters not only meets the user expectation interface, but also reduces the poor coupling between codes. We recommend "Object adaptation" at work ". Let's modify the "adapted appliances" category again:

 Code 

   Public     Class  Adapted electrical appliance: user expectation Interface
{
Electric radio  =    New  Electric Appliance ();
  Public     Void  Play in a two-hole outlet (  String  Firewire,  String  Ground)
{
  String  Zero Line  =     "  Zero Line  " ;
Radio. Play (Firewire, ground wire, zero line) under a three-hole socket );
}
} 

 

Many textbooks also mention the simplified adapter mode, that is, passing the adaptation object as a parameter to the interface method. We will also explain through the example of modifying electrical appliances.

 Code 

   Public     Interface  User expectation Interface
{
  Void  Play the video under a two-hole outlet,  String  Firewire,  String Ground );
}

  Public     Class  Adapted electrical appliance: user expectation Interface
{
  Public     Void  Play the video under a two-hole outlet,  String  Firewire,  String  Ground)
{
  String  Zero Line  =    ""  ;
Three-hole electrical appliance. Play (Firewire, ground wire, zero line) under the three-hole electrical outlet );
}
}
  Static     Void  Main (  String  [] ARGs)
{
Electric radio  =     New  Electric Appliance ();
New electrical appliance after adaptation  =     New  Adapted electrical appliance ();
New electrical appliance. Play under two-hole socket (radio, "  Firewire  "  ,  "  Ground Line  "  );

Console. Read ();
} 

 

The working principle is very simple. Let's take a closer look.

Many of my friends think that the adapter, proxy, and decoration combine an existing object and call the method of this object to implement their own functions, in fact, the structure mode is inherited and combined to implement new functions. If we look at the implementation process, they are indeed very similar, but if we analyze the intention, their difference will be big.
In the proxy mode, the complex part is extracted to the middle layer. The middle layer (proxy layer) is used to control access to the target object. The proxy layer and the interface of the target object must be the same. The adapter mode solves the problem that an existing object cannot work due to a change in the interface. By combining the existing object, the existing interface is converted to the target interface.
The decoration mode emphasizes dynamic extension of object functions through combination. For example, the above-mentioned Electric radio has its own playing function. Now there are many kinds of recorders (Japanese and Chinese), and a recorder is assembled on this radio, in addition to the playback function, apsaradb for memcache also provides the recording function. It also assembles different recorders and provides the recording function in different languages. This requirement is the application scenario of the decoration model. It is significantly different from the adapter mode care graph.

If you only talk about "How to Implement the adapter", it is much easier to explain "why and when to use the adapter mode, the above is my understanding of the "adapter mode" at this level. I believe that everyone in the design mode will have a different understanding of the different work experience, you are welcome to discuss and correct the deviations in my understanding.