Три похожих API - лучший дизайн шаблона?

Question

Я ищу некоторые мысли о том, какие шаблоны проектирования использовать для моей проблемы, независимо от языка.

Я обращаюсь к трем API-интерфейсам, которые имеют разные интерфейсы и функциональные возможности, но все они предназначены для одной цели, возвращая мне единообразным образом информацию об одном и том же контенте - авторах блогов.

Некоторые API выполняют именно то, что я хочу, некоторые требуют API + Scraping и т. Д.

Кажется, очевидным выбором является шаблон адаптера, но я хочу по-настоящему разобраться в дизайне этой вещи, и поэтому ваши мысли будут высоко оценены!

Чтобы быть совершенно ясным, сейчас я представляю один класс для каждого веб-сервиса, который выполняет как базовые функции API, так и менее элегантные. Я полагаю, что он возвращает единообразные результаты в свой адаптер. Я предполагаю, что Адаптер берет метод, такой как Поиск, а затем направляет его к соответствующему методу в API и возвращает результаты, которые будут выглядеть одинаково независимо от того, какая служба была вызвана.

Если это звучит как домашнее задание, то оно есть - но это я назначил себе, чтобы выучить некоторые классные шаблоны дизайна. Адаптер прав? Любые другие хорошие варианты?

Заранее спасибо!

ОБНОВЛЕНИЕ: Хотя мне кажется, что паттерны Адаптер и Фасад имеют много общего, Павел Дида ниже указывает на то, что я описываю на самом деле Фасад, а не Адаптер. Согласен. Кто-нибудь думает, что есть лучший вариант, чем Facade, предполагающий растущее число API-интерфейсов с течением времени?

Еще раз спасибо.

Answer 1

Адаптер - это шаблон проектирования, который адаптирует существующий API к другим существующим API.То, на что вы ссылаетесь, на самом деле является фасадом, и да, похоже, это хороший путь.

Answer 2

Не думаю, что вам нужны шаблоны фасадов или адаптеров. Мне кажется, это простой случай наличия интерфейсов с несколькими конкретными реализациями. Например:

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);
    }
}

При таком типе настройки вы можете использовать один шаблон проектирования - шаблон Factory. Например:

public class BlogFactory
{
    public IBlogApi GetApiForUrl(string url)
    {
        // Dumb example...
        if (url.Contains(".blogger.com"))
        {
            return new BloggerApi();
        }
        // ...
    }
}

Answer 3

Походит на Фасадный Образец.Всегда полезно инкапсулировать интерфейсы API сторонних производителей вдали от остального кода.Следующий шаг прочитайте, по крайней мере, книгу GoF Pattern.Он описывает большинство шаблонов в понятной форме.

Answer 4

Тип утка, добавьте метод getAuthorInfo () к каждому классу, возможно, добавьте интерфейс, но это, вероятно, даже не нужно.

Преждевременная абстракция - корень всех зол.