Adapter in [design mode)

The adapter mode is defined to convert an interface of a class to another interface that the client expects. The adapter allows classes that cannot work together due to incompatibility of interfaces to work together.
Convert the interface of a class into another interface clients except CT. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.

The intent (intent) of the adapter mode is to convert the existing interface to adapt to the target interface. An adapter can have multiple adaptee, while an adapter can also increase the functionality that adaptee does not have.

The adapter can have two versions, one is the Object Adapter, the adapter and adaptee are the relationship of HAS-A; the other is the class adapter, the adapter inherits from adaptee, the two types have their own advantages and disadvantages.
The class adapter requires multiple inheritance, the target interface requires public inheritance, and the adaptee implementation requires private inheritance, so that adaptee and target can be distinguished.

According to the introduction in Header first design patterns, the class dapter must use multiple inheritance. Isn't this correct?
Because the adapter implements the Target Interface and inherits (extend) The adaptee class, the class adapter can still be implemented without many inheritance.
The adapter can be used in different languages. For example, the two-way class adapter can only be used in languages that support multiple inheritance. The two-way class adapter can adapt to multiple adaptee,
In essence, the adapter can rewrite functions that implement the same but different signatures.

The sample code for adapter mode in Header first design patterns is as follows:

Its intent is to adapt a turkey to a duck.

Define the interfaces of duck and Turkey respectively.

public interface Duck {    public void quack();    public void fly();}

public interface Turkey {    public void gobble();    public void fly();}

Then implement two interfaces

public class MallardDuck implements Duck {    public void quack() {        System.out.println("Quack");    }    public void fly() {        System.out.println("I'm flying");    }}

public class WildTurkey implements Turkey {    public void gobble() {        System.out.println("Gobble gobble");    }    public void fly() {        System.out.println("I'm flying a short distance");    }}

Adapt Turkey to duck Using Object Adapter

public class TurkeyAdapter implements Duck {    Turkey turkey;    public TurkeyAdapter(Turkey turkey) {        this.turkey = turkey;    }    public void quack() {        turkey.gobble();    }    public void fly() {        for (int i = 0; i < 5; i++) {            turkey.fly();        }    }}

When the customer uses turkeyadapter, the duck method is called. The trukey of the action is actually transparent to the client.

Write test driver:

public class DuckTestDrive {    public static void main(String[] args) {        MallardDuck duck = new MallardDuck();        WildTurkey turkey = new WildTurkey();        Duck turkeyAdapter = new TurkeyAdapter(turkey);        System.out.println("The Turkey says...");        turkey.gobble();        turkey.fly();        System.out.println("\nThe Duck says...");        testDuck(duck);        System.out.println("\nThe TurkeyAdapter says...");        testDuck(turkeyAdapter);    }    static void testDuck(Duck duck) {        duck.quack();        duck.fly();    }}

A little bit of sentiment:
The intention of each model (intent) must be clarified when learning the design model. In fact, many models are similar or cross-cutting in implementation, the specific nuances are reflected in their intentions.
The logic of Chinese is not as good as that of English. Therefore, to keep the logic tight, it is natural that some sentences can be translated into Chinese, so it does not mean that they can be translated.