Adapter Design Pattern

Video Lecture

Section	Video Links
Adapter Pattern
Adapter Use Case

Overview

Sometimes classes have been written, and you don't have the option of modifying their interface to suit your needs. This happens if the method you are calling is on a different system across a network, a library that you may import or generally something that is not viable to modify directly for your particular needs.

The Adapter design pattern solves these problems:

• How can a class be reused that does not have an interface that a client requires?
• How can classes that have incompatible interfaces work together?
• How can an alternative interface be provided for a class?

You may have two classes that are similar, but they have different method signatures, so you create an Adapter over top of one of the method signatures so that it is easier to implement and extend in the client.

An adapter is similar to the Decorator in the way that it also acts like a wrapper to an object. It is also used at runtime; however, it is not designed to be used recursively.

It is an alternative interface over an existing interface. Furthermore, it can also provide extra functionality that the interface being adapted may not already provide.

The adapter is similar to the Facade, but you are modifying the method signature, combining other methods and/or transforming data that is exchanged between the existing interface and the client.

The Adapter is used when you have an existing interface that doesn't directly map to an interface that the client requires. So, then you create the Adapter that has a similar functional role, but with a new compatible interface.

Terminology

• Target: The domain specific interface or class that needs to be adapted.
• Adapter: The concrete adapter class containing the adaption process.
• Adapter Interface: The interface that the adapter will need to implement in order to make the target compatible with the client.
• Client: The client application that will use the Adapter.

Adapter UML Diagram

Source Code

In this concept source code, there are two classes, ClassA and ClassB, with different method signatures. Let's consider that ClassA provides the most compatible and preferred interface for the client.

I can create objects of both classes in the client, and it works. But before using each objects method, I need to do a conditional check to see which type of class it is that I am calling since the method signatures are different.

It means that the client is doing extra work. Instead, I can create an Adapter interface for the incompatible ClassB, that reduces the need for the extra conditional logic.

./src/adapter/adapter-concept.ts

// Adapter Concept Sample Code

interface IA {
    methodA(): void
}

class ClassA implements IA {
    methodA() {
        console.log('method A')
    }
}

interface IB {
    methodB(): void
}

class ClassB implements IB {
    methodB() {
        console.log('method B')
    }
}

class ClassBAdapter implements IA {
    // ClassB does not have a methodA, so we can create an adapter

    #classB: ClassB

    constructor() {
        this.#classB = new ClassB()
    }

    methodA() {
        'calls the class b method_b instead'
        this.#classB.methodB()
    }
}

// The Client
// Before the adapter I need to test the objects class to know which
// method to call.
const ITEMS = [new ClassA(), new ClassB()]
ITEMS.forEach((item) => {
    if (item instanceof ClassB) {
        item.methodB()
    } else {
        item.methodA()
    }
})

// After creating an adapter for ClassB I can reuse the same method
// signature as ClassA (preferred)
const ADAPTED = [new ClassA(), new ClassBAdapter()]
ADAPTED.forEach((item) => {
    item.methodA()
})

Output

node ./dist/adapter/adapter-concept.js
method A
method B
method A
method B

SBCODE Editor

<>

Adapter Use Case

The example client can manufacture a Cube using different tools. Each solution is invented by a different company. The client user interface manages the Cube product by indicating the width, height and depth. This is compatible with the company A that produces the Cube tool, but not the company B that produces their own version of the Cube tool that uses a different interface with different parameters.

In this example, the client will re-use the interface for company A's Cube and create a compatible Cube from company B.

An adapter will be needed so that the same method signature can be used by the client without the need to ask company B to modify their Cube tool for our specific domains use case.

My imaginary company needs to use both cube suppliers since there is a large demand for cubes and when one supplier is busy, I can then ask the other supplier.

Example UML Diagram

Source Code

./src/adapter/client.ts

// Adapter Example Use Case
import CubeA from './cube-a'
import CubeBAdapter from './cube-b-adapter'

const totalCubes = 5
let counter = 0

const manufactureCube = () => {
    // produce 5 cubes from which ever supplier can manufacture it first
    const width = Math.floor(Math.random() * 10) + 1
    const height = Math.floor(Math.random() * 10) + 1
    const depth = Math.floor(Math.random() * 10) + 1
    let cube = new CubeA()
    let success = cube.manufacture(width, height, depth)
    if (success) {
        counter = counter + 1
    } else {
        // try other manufacturer
        console.log('Company A was busy, so trying company B')
        cube = new CubeBAdapter()
        success = cube.manufacture(width, height, depth)
        if (success) {
            counter = counter + 1
        } else {
            console.log('Company B was busy, so trying company A')
        }
    }
}

// wait some time between manufacturing each cube
const interval = setInterval(() => {
    manufactureCube()
    if (counter >= totalCubes) {
        clearInterval(interval)
        console.log(`${totalCubes} cubes have been manufactured`)
    }
}, 1000)

./src/adapter/cube-a.ts

// A hypothetical Cube tool from Company A
export interface ICubeA {
    manufacture(width: number, height: number, depth: number): boolean
}

export default class CubeA implements ICubeA {
    static last_time = Date.now()

    manufacture(width: number, height: number, depth: number): boolean {
        // if not busy, then manufacture a cube with dimensions
        const now = Date.now()
        if (now > CubeA.last_time + 1500) {
            console.log(
                `Company A built Cube with dimensions ${width}x${height}x${depth}`
            )
            CubeA.last_time = now
            return true
        }
        return false // busy
    }
}

./src/adapter/cube-b.ts

// A hypothetical Cube tool from Company B
export interface ICubeB {
    create(
        top_left_front: [number, number, number],
        bottom_right_back: [number, number, number]
    ): boolean
}

export default class CubeB implements ICubeB {
    static last_time = Date.now()

    create(
        top_left_front: [number, number, number],
        bottom_right_back: [number, number, number]
    ): boolean {
        // if not busy, then manufacture a cube with coords
        const now = Date.now()
        if (now > CubeB.last_time + 3000) {
            console.log(
                `Company B built Cube with coords [${top_left_front[0]},${top_left_front[1]},${top_left_front[2]}],[${bottom_right_back[0]},${bottom_right_back[1]},${bottom_right_back[2]}]`
            )
            CubeB.last_time = now
            return true
        } else {
            return false // busy
        }
    }
}

./src/adapter/cube-b-adapter.ts

// Adapter for CubeB that implements ICubeA
import { ICubeA } from './cube-a'
import CubeB from './cube-b'

export default class CubeBAdapter implements ICubeA {
    #cube: CubeB

    constructor() {
        this.#cube = new CubeB()
    }

    manufacture(width: number, height: number, depth: number): boolean {
        const success = this.#cube.create(
            [0 - width / 2, 0 - height / 2, 0 - depth / 2],
            [0 + width / 2, 0 + height / 2, 0 + depth / 2]
        )
        return success
    }
}

Output

node ./dist/adapter/client.js
Company A was busy, so trying company B
Company B was busy, so trying company A
Company A built Cube with dimensions 6x5x10
Company A was busy, so trying company B
Company B built Cube with coords [-4,-3,-2.5],[4,3,2.5]
Company A built Cube with dimensions 4x5x3
Company A was busy, so trying company B
Company B was busy, so trying company A
Company A built Cube with dimensions 10x2x1
Company A was busy, so trying company B
Company B built Cube with coords [-0.5,-2,-2.5],[0.5,2,2.5]
5 cubes have been manufactured

SBCODE Editor

<>

Summary

• Use the Adapter when you want to use an existing class, but its interface does not match what you need.
• The adapter adapts to the interface of its parent class for those situations when it is not viable to modify the parent class to be domain-specific for your use case.
• Adapters will most likely provide an alternative interface over an existing object, class or interface, but it can also provide extra functionality that the object being adapted may not already provide.
• An adapter is similar to a Decorator except that it changes the interface to the object, whereas the decorator adds responsibility without changing the interface. This also allows the Decorator to be used recursively.
• An adapter is similar to the Bridge pattern and may look identical after the refactoring has been completed. However, the intent of creating the Adapter is different. The Bridge is a result of refactoring existing interfaces, whereas the Adapter is about adapting over existing interfaces that are not viable to modify due to many existing constraints. E.g., you don't have access to the original code, or it may have dependencies that already use it and modifying it would affect those dependencies negatively.