Adapter Design Pattern

Structural Design Pattern

The ‘Adapter’ design pattern is a structural design pattern for assembling classes and objects into a bigger system.

Even though their interfaces are incompatible, the ‘Adapter’ pattern allows two objects with related functionalities to work together.

When should this pattern be used?

To allow objects with incompatible interfaces to collaborate This pattern should be used when we need two objects to collaborate, even though their interfaces are incompatible. When the other object interface differs from the one intended, an object does not know which method to use. The ‘Adapter’ pattern solves this problem by presenting an object with the existing code that needs to be adapted that adheres to the required interface. Converting the intricacy of conversion to an interface makes it easier to use its features. This object, known as an adaptor, hides the conversion’s complexity.

To combine components that have similar functions

When two components with distinct interfaces but comparable capabilities must work together, this pattern should be employed. If the functions of the components differ, the ‘Adapter’ pattern will add, remove, or change their behaviors, which is not the aim. Its job is to transform one interface to another, allowing interfaces to communicate with one another. We don’t want to force the integration of a component that doesn’t deliver the capabilities that the interface it’s being adapted for requires.

To separate an object from its interface implementation

When we have two unrelated interfaces that need to communicate with each other and the target/needed interface varies over time, we should utilize this approach. We utilize a middleman to separate implementation details from client code, decrease dependencies, and protect our code from API changes. It’s an object that translates requests from the current interface to the one that’s required. It wraps code modifications, requiring no changes to the client. We enhance the behavior without changing the code’s implementation. It makes our client extensible but not modifiable (the Open/Closed Principle).

Practice

We are going to describe a short example of a Swift implementation of the adapter pattern. Let’s assume that we would like to build an app to show person list from our DB. We got an API structure that looks like this:

struct Person {

var name: String

var surname: String

var age: Int

var gender: String

}

However, within the app we don’t prefer to use API models in interface layer. So, we need to decouple this from UI layer.

protocol PersonUI {

var fullName: String { get }

var personAge: Int { get }

}

Well, we will use PersonUI instance at interface layer, this plays converter role between our API layer and UI layer.

At this point, we have API layer model, UI layer model ( converter). We need only to convert API model to UI model. By help of conformance to protocol, we can handle this task.

extension Person : PersonUI {

var fullName: String {

return name + surname

}

var personAge: Int {

return age

}

}

Summary

The ‘Adapter’ pattern is a structural design pattern for assembling classes and objects into a bigger system. This pattern should be used when we need two objects to collaborate, even though their interfaces are incompatible. Its job is to transform one interface to another, allowing interfaces to communicate with one another. A middleman is an object that translates requests from the current interface to the one that’s required. It wraps code modifications, requiring no changes to the client. It makes our client extensible but not modifiable (the Open/Closed Principle), and decrease dependencies.

Thanks

Much grateful to you for following me and my stories. Happy to have you here, and would like to make it worth your time.