Adapter is a structural design pattern that allows objects with incompatible interfaces to collaborate.

Adapter Design Pattern

This is a special object that converts the interface of one object so that another object can understand it.

Adapter convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces.

Use the pattern when you want to reuse several existing subclasses that lack some common functionality that can’t be added to the superclass.

How Adapter works

1. The adapter gets an interface, compatible with one of the existing objects.
2. Using this interface, the existing object can safely call the adapter’s methods.
3. Upon receiving a call, the adapter passes the request to the second object, but in a format and order that the second object expects.

Object adapter

1. Client is a class that contains the existing business logic of the program.
2. Client Interface describes a protocol that other classes must follow to be able to collaborate with the client code.
3. Service is some useful class (usually 3rd-party or legacy). The client can’t use this class directly because it has an incompatible interface.
4. Adapter is a class that’s able to work with both the client and the service: it implements the client interface, while wrapping the service object. The adapter receives calls from the client via the adapter interface and translates them into calls to the wrapped service object in a format it can understand.

Class Adapter

It doesn’t need to wrap any objects because it inherits behaviors from both the client and the service. The adaptation happens within the overridden methods. The resulting adapter can be used in place of an existing client class.

Implement

1. Make sure that you have at least two classes with incompatible interfaces
2. Declare the client interface and describe how clients communicate with the service.
3. Create the adapter class and make it follow the client inter- face. Leave all the methods empty for now.
4. Add a field to the adapter class to store a reference to the service object.
5. One by one, implement all methods of the client interface in the adapter class.
6. Clients should use the adapter via the client interface. This will let you change or extend the adapters without affecting the client code.

Problem : Employee work Time

We have an object for employee that calculated worked time per hour also each employee must has a contract that calculate worked time per day. each employee works 8 hours per day so if employee worked 2 days it calculated => 2* 8 = 16 hours worked for 2 days

• We do not add new function to Employee class because of Open–closed principle (OCP)

interface IEmployee {
     work_in_hour(): number;
}
class Employee implements IEmployee {
      public hour_worked: number;
      constructor(hour_worked: number) {
          this.hour_worked = hour_worked;
      }
      work_in_hour(): number {
         return this.hour_worked;
      }
}
interface IContractor {
     work_in_day(): number;
}

class Contractor implements IContractor {
     public day_worked: number;
     constructor(day_worked: number) {
        this.day_worked = day_worked;
     }
     work_in_day(): number {
       return this.day_worked;
     }
}
class ContractorAdapter implements IEmployee {
      private contractor: IContractor;
      constructor(contractor: IContractor) {
          this.contractor = contractor;
      }
      work_in_hour() {
         return this.contractor.work_in_day() * 8;
      }
}
class EmployeeAdapter implements IContractor {
      private employee: IEmployee;
      constructor(employee: IEmployee) {
         this.employee = employee;
      }
      work_in_day() {
       return this.employee.work_in_hour() / 8;
     }
}
let employee_1 = new Employee(200);
let contractor_1 = new Contractor(19);
// 19 day = 152 hours
const to_hour = new ContractorAdapter(contractor_1).work_in_hour();
// 200 hours = 25 days
const to_day = new EmployeeAdapter(employee_1).work_in_day();

Pros

• Single Responsibility Principle. You can separate the interface or data conversion code from the primary business logic of the program.
• Open/Closed Principle. You can introduce new types of adapters into the program without breaking the existing client code, as long as they work with the adapters through the client interface.

Cons

• The overall complexity of the code increases because you need to introduce a set of new interfaces and classes. Sometimes it’s simpler just to change the service class so that it matches the rest of your code.