views:

126

answers:

4

Hey guys,

I'm looking for some thoughts on which design pattern(s) to use for my problem, regardless of language.

I am accessing three APIs that have different interfaces and functionality, but are all for the same purpose, returning information to me, in a uniform way, about the same kind of content -- blog authors.

Some APIs do exactly what I want, some will require API + Screen Scraping, and so on.

The obvious choice seems to be Adapter pattern but I want to really dig into the design of this thing and as such your thoughts would be greatly appreciated!

To be totally clear, right now I envision one class per web service that both does the basic API stuff as well as the less elegant stuff. I imagine it then returns uniform results to its Adapter. I imagine the Adapter takes a method like Search and then routes it to the appropriate method in the API, and gets back the results, which will look the same regardless of which service was called.

If this sounds like a homework assignment, it is -- but it's one I've assigned to myself in order to learn some cool design pattern stuff. Is Adapter right? Any other good options?

Thanks in advance!

UPDATE: While Adapter and Facade patterns seem to me to share a lot of similarities, Paweł Dyda points out below that what I'm describing is really Facade rather than Adapter. I agree. Does anyone think that there is a better option than Facade, assuming a growing number of APIs over time?

Thanks again.

A: 

Duck type, add a getAuthorInfo() method to each class maybe add an Interface but that's probably not even necessary.

Premature abstraction is the root of all evil.

alper
I tend to disagree. Everything depends on the size of the project. If (s)he knows that the project will evolve into some monster in terms of size, good abstractions are actually needed and should be used thoroughly.
Paweł Dyda
Thanks both! I'm looking into Facade now.
+2  A: 

Adapter is a design pattern that adapt existing API to other existing API. What you are referring to, is actually Façade and yes, it seems like good way to go.

Paweł Dyda
+2  A: 

I don't think you need the Façade or adapter patterns. This seems to me to be a simple case of having interfaces with multiple concrete implementations. For example:

interface IBlogApi
{
    IBlog GetBlog(string url);
}

interface IBlog
{
    AuthorInfo GetAuthorInfo();
}

class BloggerBlog : IBlog
{
    public BloggerBlog(string url)
    {
        // ...
    }

    public AuthorInfo GetAuthorInfo()
    {
        // ...
    }
}

class BloggerApi : IBlogApi
{
    public IBlog GetBlog(string url)
    {
        return new BloggerBlog(url);
    }
}

With this type of setup, one design pattern you could employ is the Factory pattern. For example:

public class BlogFactory
{
    public IBlogApi GetApiForUrl(string url)
    {
        // Dumb example...
        if (url.Contains(".blogger.com"))
        {
            return new BloggerApi();
        }
        // ...
    }
}
Jacob
I was kind of hoping someone would suggest Factory. I will give your approach serious thought. Thanks.
A: 

Sounds like Facade Pattern. It's always a good idea to encapsulate 3rd party api interfaces away from the rest of your code. Next Step read at least the GoF Pattern book. It describes the most patterns in a clear software engineerish way.

jami
Thanks. Facade is starting to seem like a good bet.