Analysis of adapter Design patterns in C #

Transform the interface of a class into another interface that the client expects, so that the two classes that do not match the original interface can work together.

Intention

Transform the interface of a class into another interface that the client expects, so that the two classes that do not match the original interface can work together.

Scene

Suppose that the client program for the network game is divided into two parts. Part of the lobby section that communicates with the service side, the lobby section provides the features to buy, read the room list, create a room, and start the game program. The other part is the game program, the game program and the lobby program, although belonging to a client, but by different companies in the development. The game lobby communicates by implementing the agreed interface and game program.

The first design is that the lobby program is based on the interface to invoke the game program to start the game scene method. As the lobby process is nearing completion, the company decides to work with another gaming company, so it wants to apply the lobby program to another game. And this new game is followed by another set of interfaces. Is it possible to avoid modifying the original calling method to start the scene? Perhaps you would say, since there is only one way to modify, then there is no harm to modify it, we assume that there are 100 interfaces between the hall program and the game program, most of which are modified? Because of the modification of the Game program Interface, the hall program may have to be modified in more than 100 places. What is the point of this interface?

You can consider using the adapter mode to fit the mismatch of this interface at this point.

The following are the referenced contents: Using System; Using System.Collections.Generic; Using System.Text; Namespace Adapterexample {class Program {static void Main (string[] args) {Lobby Lobby = new Lobby (); Lobby. Createroom ("Halfpaper"); Lobby. Startgame (); } interface Igame {void Startscene (string scenename); void Enterplayer (string playername); Class Lobby {private string scenename; public void Createroom (string scenename) {this.scenename = Scenename; public void Startgame () {igame game = new Gameadapter (); Game. Startscene (Scenename); Game. Enterplayer ("Yzhu"); } class Game {public void Loadscene (string scenename, string token) {if (token = "Abcd1234") Console.WriteLine ("Loading" + Scenename + "..."); else Console.WriteLine ("Invalid token!"); public void Enterplayer (int playerid) {Console.WriteLine ("Player:" + playerID + "entered"); } class Gameadapter:igame {private Game Game = new Game (); public void Startscene (string scenename) {game. LoadscENE (Scenename, "Abcd1234"); public void Enterplayer (string playername) {game. Enterplayer (Getplayeridbyplayername (playername)); private int Getplayeridbyplayername (string playername) {return 12345; } } }

As you can see, in the original interface, starting the game scene requires only one parameter, the game scene name, and the new player needs to provide the player ID (the new game uses the player ID instead of the player account name).

The Igame interface is the target role in the adapter pattern, which is the interface that the customer expects. It is also the interface that is followed by the old game program.

The lobby class is equivalent to the caller or customer, and its original code may be as follows:

The following are the referenced contents: Game Game = new Game ();

However, due to the change of interface, it is not possible to instantiate the game class directly, only the adapter type can be instantiated. Although the changes are still needed, the changes are small and can be eliminated by dynamically loading the assembly.

The Gameadapter class is the adapter role, which is the core of the adapter pattern and is used to transform the source interface into the target interface. Here, we see that it implements the target interface.

The game type is the source role, or the object that needs to fit. Maybe it also follows a different set of interfaces, but we're not very concerned about this, so it's not reflected in the code.

After using the adapter mode, the client code does not make any modifications. Client code Honest dependency interface, it is not wrong, if so dependent on the modification of the object needs to be significantly modified is very innocent, we in the adapter to have no association with the two interface to fit together. As we can see, the adapter does more than just change the method name, and if the source and target roles are very different, then the adapter needs to do a lot of work.

When to use

From a code perspective, you might consider using a builder pattern if you want to separate the complex type building rules from the internal composition of the types, or if you want to use the same build process to build different types.

From an application perspective, if you want to decouple the product's creation process and the product's specific accessories, or you want to reuse a set of stable and complex logic for all product creation, consider using the builder model.

Implementation Essentials

The key to the successful application of the adapter pattern is whether the code itself is based on interface programming, and if not, the adapter is powerless.

The implementation of the adapter pattern is simple, and the basic idea is that the adapter must follow the target interface.

Adapter patterns are more varied, can be adapted by inheritance and composition, adapters can be a set of adapter products, and adapters can be abstract types.

The difference between the adapter pattern and the façade is that the former follows the interface, which can be more flexible than the interface.

The difference between adapter mode and proxy is that the former provides a different interface for the object, or provides the same interface for the object, and the former has a bit of a complementary flavor, which is applied at design time.

Attention matters

Consider the cost of adaptation when matching two unrelated classes, and a very large adapter can have an impact on system performance.