Cidenet+Blog+Clean Dev Practices+Convert an interface of a class with Adapter!

Convert an interface of a class with Adapter!

What is it? What problem does it solve?

The Adapter pattern is used to convert an interface of a class into one expected by the clients. In addition, it allows two classes that are incompatible due to interface incompatibility to work together.

This pattern is useful when:

  • You need to use an existing class and its interface is not compatible with the implemented interface in the class where such an existing class wants to be used.
  • When you already have a system and you need to add new features. Adapter allows you to do this cleanly since the existing code is not modified.
  • You want to create a reusable class that cooperates with classes that do not necessarily have compatible interfaces.


Imagen 1

  • Target: Defines the interface that the client uses.
  • Client: Provides the objects according to the Target interface.
  • Adaptee: Defines an existing interface that needs to be adapted.
  • Adapter: Adapts the Adaptee interface to the Target interface.

A good example of this pattern are the electricity connectors. Suppose you travel to Europe. There the power outlets are different from the Colombians. The problem is that the outlet cannot be changed. The solution is to buy an adapter that fits the Colombian connector and that at the same time can be connected to the European outlet.

In this case, the Target is the Colombian connector, Client is the person who owns the connector, who needs to use the outlet. Adaptee would be the European outlet that cannot be changed and the Adapter would be the Adapter that acts as a bridge between the Colombian plug and the European outlet and allows the customer to have access to electricity.


Suppose that there is an application that connects to a third-party service and that this service, in its API, states that only request bodies in XML format are allowed. Initially, the implementation is carried out and the requests are made with the corresponding XML format. Note that ExternalSDKLibrary is a class that provides the third party’s SDK and therefore cannot be modified.

public void shouldNotNeedAnAdapterOnXmlRequestBody() {
	Request request = new Request("<?xml>...");
	assertTrue(new ExternalSDKLibrary(request.getMessage()).makeRequest());

But after time, the application needs to receive requests in JSON format, however, the SDK still does not allow requests with such format. In this situation, you can create an adapter that converts the JSON request to XML to later make a request to the third party’s SDK.

To do this, an interface is created that represents the necessary methods for the adapter to establish communication between the JSON request and the request expected by the third party.

public interface JSONToXMLAdapter {
	boolean makeRequest();


Then, the adapter is created as such, which must implement the interface previously presented. This adapter must contain an object of the client class as an attribute. In this case, this class contains the request in JSON format. This class is the one that is not supported by the SDK.

In the implemented makeRequest method, the JSON response from the request class is converted to XML using the ConvertToXML method. Having this conversion done, the third party’s SDK method can now be called correctly as presented in code 4.

public class JSonToXMLAdapterImpl implements JSONToXMLAdapter {
	private final Request request;

	public JSonToXMLAdapterImpl(Request request) {
		this.request = request;

	public boolean makeRequest() {
		ExternalSDKLibrary externalSDKLibrary = convertToXML();
		return externalSDKLibrary.makeRequest();

	private ExternalSDKLibrary convertToXML() {
		return new ExternalSDKLibrary("<?xml>" + request.getMessage());



This way, the SDK can be used, even though initially requests are being received in JSON format.


public void ShouldNeedAnAdapterOnJSONRequestBody() {
	JSonToXMLAdapterImpl jSonToXMLAdapter = 
	       new JSonToXMLAdapterImpl(new Request("{"campo": "valor"}"));

In the scenario of requiring allowing petitions in a different format by the client, it is only necessary to create a new adapter for that new type of format.

Note that the usefulness of the Adapter pattern relies on being able to use an unsupported interface that cannot be modified, either because the code is foreign to the system or because the code is part of the system, but its modification would imply significant changes elsewhere in the application. , or, because it is a legacy application.

Sample code and an additional example can be found at:


  • An advantage of the Adapter pattern is that it is not necessary to change the existing interface, avoiding changes in the existing code, ensuring that collateral effects are not generated in other components of the application.
  • Adapter makes things work after they have been designed. for example, in cases where the initial design was not optimal.
  • This is useful when you are migrating a legacy application and there are still modules in it that are required because they have not been migrated.
  • Helps to reuse code.




Contact us

Allow us to contact you

    Medellín - Colombia

  • Carrera 69 #49A - 11 Barrio Suramericana
  • (+57) 312 8475682

    United States

  • 1200 Colorado Blvd, Denver Colorado 80220
  • (+1) 7723619239