Some situations or cases to use Adapter pattern [closed]

Question

I am just a starter to design patterns and just learned the theoretical definition and also how to implement in code but love to know various real world situation/cases/scenarios that encourages to use Adapter pattern?

Examples in C# appreciated.

Answer 1

Let's say you have a class that parses HTML files to make sure they are valid. It looks like this:

public class Parser
{
    public Parser(string filePath)
    {
        ...
    }

    public void Parse()
    {
        ...
    }

    public bool IsValid()
    {
        ...
    }
}

And let's say you are using it in an application. The application code might look like this:

Parser p = new Parser("file.html");
p.Parse();

if(p.IsValid())
    print "yay"
else
    print "lame"

You wrote the Parser class and it works pretty well but your friend wrote another that works even better. Let's say their class looks like this:

public class BetterParser
{
    public bool ParseHtml(FileStream fs)
    {
        ...
    }
}

Now you want to use your friend's BetterParser class instead of your Parser class, but it doesn't really work with your code because it has different method names and a slightly different way of working. You could just change the application code above to something like this:

FileStream fs = GetStream("test.html")
BetterParser bp = new BetterParser()

if(bp.ParseHtml(fs))
    print "yay"
else
    print "lame"

And that's fine, but what if you have a large application where your Parser class is used everywhere? You may not really want to go changing all the places where it's used because that would require a lot of extra testing and potential bugs.

What you could do would be to use the adapter pattern to change your class to actually use your friend's class inside its implementation.

class Parser
{
    private BetterParser bp = new BetterParser();
    private FileStream fs;
    private boolean successful;

    public Parser(string file)
    {
        fs = GetStream(file);
    }

    public void Parse()
    {
        successful = bp.ParseHtml(fs);
    }

    public boolean IsValid()
    {
        return successful;
    }
}

You can see that now the implementation of your class uses your friend's class behind the scenes. So now all the code that uses your Parser class doesn't have to change and you can still get the benefits of using the better parser.

That's basically what the adapter pattern is all about. It connects two things that cannot directly connect to each other. In this case, the Parser class used to be a normal HTML parser, but it changed into an adapter that connects your application code to your friend's parser.

It's all about separating the interface from the implementation. Your application code should not rely on how the parser class works internally, but it must rely on the interface to that class. The fact that the class has a constructor that takes a file path, the fact that it has a method called Parse that takes no arguments, and a method called IsValid that returns a boolean. These are all aspects of the class' interface and if that interface changes, your application can no longer use that class without making changes as well. So instead you keep the interface the same and change the implementation.

It's bigger than classes

People often say that an adapter is just a "wrapper" around another class. That's probably true a lot of the time when it comes to adapters at the code level. However, entire applications can also serve as adapters. Let's say you had some server provides some XML web service API (i.e. SOAP). That means all the clients that talk to it need to understand XML. What if you wanted to hook up a client that didn't speak XML (maybe it uses JSON)? Well one option would be to put a box in between the server and the JSON box. This new box would serve as an adapter that could translate between XML and JSON. The client talks to the adapter using JSON, the adapter talks to the server using XML.