Category: Structural design patterns

Purpose: To convert legacy code (usually a library)/ tripartite code into a new interface that can be used in projects using the new interface

1drv.ms/u/s! AquRvPz…

A typical scenario

Take a payment module in the system as an example. A payment module will connect with multiple payments, such as wechat and Alipay

Basic facts

In existing code, a payment method is already being used to process orders, and the corresponding payment interface pay.java is referenced below

public interface Pay {
    void setAmount(Integer amount);
    void makePayment(a);
}
Copy the code

The implementation of the above interface is payimp.java

public class PayImpl implements Pay {
    @Override
    public void setAmount(Integer amount) {
        System.out.println("set pay impl");
    }

    @Override
    public void makePayment(a) {
        System.out.println("make payment"); }}Copy the code

In ServicemyService.java, payment is used to process orders as follows:

public class MyService {
    public void processOrder(Pay pay) {
        pay.setAmount(1); pay.makePayment(); }}Copy the code

Call the reference

var myservice = new MyService();
var pay = new PayImpl();
myservice.processOrder(pay);
Copy the code

The running effect is as follows:

Plug in a new payment method

New payment methods such as Pay1 interface pay1. service refer to the following:

public interface Pay1 {
    void init(a);
    void setPrice(Integer amount);
    void processPay(a);
}
Copy the code

The corresponding implementation is pay1imp.java

public class Pay1Impl implements Pay1 {
    @Override
    public void init(a) {
        System.out.println("pay1 init");
    }

    @Override
    public void setPrice(Integer amount) {
        System.out.println("pay1 set amount");
    }

    @Override
    public void processPay(a) {
        System.out.println("pay1 make payment"); }}Copy the code

Compare to existing payment interfaces

Pay1.java Pay.java
init There is no
setPrice setAmount
processPay makePayment

You can see that the interface used for the third-party payment method is different from the existing one in the project, so it cannot be used directly in MyService (see the editor’s hint).

Pattern implementation

It is to adapt the new third-party payment method Pay1 to Pay required by the current project, and add a new class such as Pay1Adapter for interface conversion

The pay1Adapter.java reference is as follows:

public class Pay1Adapter implements Pay {
    private Pay1 pay1;
    
    public Pay1Adapter(Pay1 pay1) {
        this.pay1 = pay1;
    }

    @Override
    public void setAmount(Integer amount) {
        pay1.init();
        pay1.setPrice(amount);
    }

    @Override
    public void makePayment(a) { pay1.processPay(); }}Copy the code

The adaptation effect is as follows

You can see that after adaptation, Pay1 can be used in projects that require a Pay interface

The Pay1Adapter that converts a Pay1 interface into a Pay interface is the adapter

UML

Why use adapters

  1. Reuse tripartite code with as little code as possible
  2. Avoid directly modifying three-party code

A couple of points to note

Generally, the third-party SDK does not adapt for a system alone, so it needs to adapt by itself

The resources

  1. www.geeksforgeeks.org/adapter-pat…