Ramble: How do I explain adapter mode to my girlfriend?

​

Weekend nest in the home to play king of glory, my girlfriend next to play my computer, I suspect she broadcast variety show sound is quite loud, so suggested she wear headphones.

Adapter Pattern, often translated as Adapter Pattern and sometimes called wrapper Pattern, is one of GOF’s 23 design patterns. The main function is to convert the interface of one class into another interface that the customer wants. The adapter pattern makes it possible for classes to work together that would otherwise not work because of interface incompatibilities.

The Design Patterns: Elements of Reusable Object-oriented Software (Design Patterns), Written by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (Addison-Wesley, 1995). These authors are often referred to as the Gang of Four, or GOF.

GOF divides the adapter pattern into class adapter pattern and object adapter pattern.

Object adapter pattern

In this adapter pattern, the adapter holds an instance of the class it wraps around. In this case, the adapter calls the physical entity of the wrapped object.

Adapter-like pattern

In this adapter pattern, the adapter inherits from the classes it implements (generic multiple inheritance).

The only difference is whether the adapter role ADAPTS to the role to be adapted through inheritance or composition, since Java does not support multiple inheritance, and the adapter-like pattern breaks encapsulation, and we advocate more composition and less inheritance. So this article focuses on object adapters.

We often need to use the socket converter in our life, for example, many mobile phones now have only one socket, which can be directly used to charge and listen to music. But the premise is that the charger and earphone jack we use should be compatible with the device.

At present, many mobile phones in the market have type-c or Lightning ports:

However, the headset models we commonly use are 2.5mm and 3.5mm round ports:



So, when we want to plug our 3.5mm round earphones into Lightning or Type-C, we need a converter:

1. The system needs to use existing classes, but the interface of this class does not meet the needs of the system.

2. You want to create a reusable class that works with classes that are not closely related to each other, including classes that may be introduced in the future and whose source classes do not necessarily have a consistent interface.

3. Insert a class into another class family by interface conversion. (For example, tigers and birds, now more than a flying tiger, without the need to increase the entity, add an adapter, containing a tiger object in the interface to achieve flying.)

The adapter pattern solves these problems.

Let’s use the adapter mode to simulate a scenario: use an Android Type-C charger to charge an iPhone that only supports the Lightning port (assuming it works perfectly).

We know we have a Type-c charger and a Lightning jack iPhone. Both Type-C and Lightning are standards. In code, standards are interfaces. So let’s first define two interfaces:

/** * Lightning charge port */ public interface LightningInterface {public void chargeWithLightning(); } /** * TypeC charge interface */ public interface TypeCInterface {public void chargeWithTypeC(); }Copy the code

Next, define our iPhone, which only supports charging using the Lightning jack:

public class IphoneX {

    private LightningInterface lightningInterface;

    public IphoneX() {
    }

    public IphoneX(LightningInterface lightningInterface) {
        this.lightningInterface = lightningInterface;
    }

    public void charge() {
        System.out.println("Start charging my IphoneX...");
        lightningInterface.chargeWithLightning();
        System.out.println("Finish charging my IphoneX...");
    }
    //setter/getter
}Copy the code

Then let’s look at how our Android charger should be defined:

/** * Public class AndroidCharger implements TypeCInterface {@override public voidchargeWithTypeC() {
        System.out.println("Charge with a Type-c charger..."); }}Copy the code

With android chargers and iphones. Next, we are going to define an adapter, which we hope can be used to charge the iPhone using the android device charger:

public class Adapter implements LightningInterface {
    private TypeCInterface typeCInterface;

    public Adapter() {
    }

    public Adapter(TypeCInterface typeCInterface) {
        typeCInterface = typeCInterface;
    }

    @Override
    public void chargeWithLightning() {
        typeCInterface.chargeWithTypeC();
    }

    //setter/getter
}Copy the code

This adapter implements LightningInterface and combines TypeCInterface, when external call chargeWithLightning method actually calls is TypeCInterface chargeWithTypeC method.

Just like the power adapter, it implements a Lightning specification and itself is a Lightning plug, but when it is actually charged, it is carried out through the typC-C power supply, and it plays a role of intermediate conversion.

Then we define the client to implement the charging function we want:

public class Main { public static void main(String[] args) { Adapter adapter = new Adapter(new AndroidCharger()); IphoneX iphoneX = new IphoneX(); iphoneX.setLightningInterface(adapter); iphoneX.charge(); }}Copy the code

The following output is displayed:

Start charging my IphoneX... Charge with type-c charger... End of charging my IphoneX...Copy the code

In the example above, we used an Android Type-C charger to charge an iPhone with Lightning only port via an adapter.

The above code is an example of an adapter pattern in which there are four roles:



Among the above four roles, the target abstract class (Lightning interface), adapter class (Android charger) and client (iPhone) are all existing in the original code, and we do not need to modify them at all. All you need to do is introduce an adapter (interface converter).

advantages

The adapter pattern (object adapter pattern) is an implementation of the idea that composition is better than integration. By using the adapter pattern, we can maximize the reuse of existing classes and code. He mainly has the following points:

• Decouple the target class from the adapter class and reuse the existing adapter class by introducing an adapter class without modifying the original code.

• Increased class transparency and reusability, encapsulation of the specific implementation in the adapter class, transparent to the client class, and improved adapter reuse.

• Flexibility and extensibility are very good, through the use of configuration files, it is easy to replace the adapter, but also without modifying the original code on the basis of the new adapter class, in full compliance with the “open closed principle”.

disadvantages

Of course, the adapter pattern is not perfect, and overuse can cause some problems. Disadvantages are as follows:

• Too much use of adapters can make the system very cluttered and difficult to grasp as a whole. For example, clearly see is called A interface, in fact, internal adaptation into the IMPLEMENTATION of THE B interface, A system if too much of this situation, is tantamount to A disaster. So if you don’t have to, you can skip the adapter and refactor your system directly.

The usage scenario of the adapter pattern is generally considered when we need to modify some running code and want to reuse the existing code for new functions.

In the Spring framework, Adapter patterns are used extensively. Readers can open their IDE and try to search globally with the keyword “Adapter”, which will definitely have many practical applications.

When you run into a problem similar to the one you’re trying to charge your iPhone with an Android charger, think adapter mode.

This is my third article on design patterns. The first two are “Ramblings: How to Explain Strategic Patterns to Your Girlfriend”. Ramblings: How to Explain singleton to A Girlfriend? What other design patterns would you like to learn, please leave a comment.