what is the need of Adapter Design pattern?

Question

In the below adapter design pattern sample code, why a new class is introduced instead of using multiple interface in the client?

interface ITarget
{
  List<string> GetProducts();
}


public class VendorAdaptee
{
   public List<string> GetListOfProducts()
   {
      List<string> products = new List<string>();
      products.Add("Gaming Consoles");
      products.Add("Television");
      products.Add("Books");
      products.Add("Musical Instruments");
      return products;
   }
}


class VendorAdapter:ITarget
{
   public List<string> GetProducts()
   {
      VendorAdaptee adaptee = new VendorAdaptee();
      return adaptee.GetListOfProducts();
   }
}


class ShoppingPortalClient
{
   static void Main(string[] args)
   {
      ITarget adapter = new  VendorAdapter();
      foreach (string product in adapter.GetProducts())
      {
        Console.WriteLine(product);
      }
      Console.ReadLine();
   }
}

I have the below queries related to the above code.

• What, if ShoppingPortalClient directly inherits VendorAdaptee?
• In which scenario we need adapter class?
• why instead of simple inheritance a needed class, creating this pattern to access another class method?

Answer 1

Sometimes you have a given API that you can't change (legacy/external-library/etc...) and you want to make your classes be able to work with that API without changing their code.

Lets say you use an API which has an ISomethingToSerialize

public interface ISomethingToSerialize
{
    object[] GetItemsToSerialize();
}

That API also has a Serialize function:

public class SerializationServices
{
    byte[] Serialize(ISomethingToSerialize objectToSerialize);
}

Now you have a class in your code, and you don't want or not able to change it, let's call it MyUnchangeableClass.

This class doesn't implement ISomethingToSerialize but you want to serialize it using the API so you create AdapterClass which implement ISomethingToSerialize to allow MyUnchangeableClass to use it without implementing it by itself:

public class AdapterClass : ISomethingToSerialize
{
    public AdapterClass(MyUnchangeableClass instance)
    {
        mInstance = instance;
    }

    MyUnchangeableClass mInstance;

    public object[] GetItemsToSerialize()
    {
        return mInstance.SomeSpecificGetter();
    }
}

Now you can use

MyUnchangeableClass instance = ... //Constructor or factory or something...
AdapterClass adapter = new AdapterClass(instance)
SerializationServices.Serialize(adapter);

to serialize an instance of MyUnchangeableClass even though it doesn't meet the requirements of the API by itself.

Answer 2

You've got the idea totally wrong. The VendorAdaptee is the instance of code that produce data, where the ShoppingPortalClient is the one who wants to consume it.

Let me explain what would be the real world situation. You are implementing the shop, and someone else has been implemented a service to give you data about their products(VendorAdaptee). The simple way of doing it is to simply call their methods and use the data, right? But it is their service and they might want to change it later while you don't want to upload your whole solution and release a new version. Therefore, you need an adapter in between to make sure that the data will be send to your real code with the format that you need, and you simply don't care about the address, method name or data format that has been supported by your vendor.

---

about your questions:

Inheritance is not in any way the case. Conceptually speaking, a shop is not a vendor in any way. considering the code, you have nothing similar in any of those 2, and the behavior is totally different. one is providing data while the other use it.

Answer 3

The main reason you would use an adapter is for legacy code that you don't want to mess with - or a third party that you won't to fit into a certain interface.

There are other reasons, usually depending on how you find easier to develop and if using the adapter design pattern makes sense to you. I don't see it as very useful in other cases though.