2010-09-18 4 views
4

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

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

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

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

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

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

Заранее благодарен!

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

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

ответ

3

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

0

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

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

+1

Я склонен не согласиться. Все зависит от размера проекта. Если (а) он знает, что проект будет развиваться в какой-то монстр с точки зрения размера, на самом деле нужны хорошие абстракции и их следует использовать основательно. –

+0

Спасибо, оба! Сейчас я смотрю в Фасад. – user277127

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(); 
     } 
     // ... 
    } 
} 
+0

Я как бы надеялся, что кто-то предложит Factory. Я серьезно подумаю о вашем подходе. Благодарю. – user277127

0

Звучит как шаблон фасада. Всегда рекомендуется инкапсулировать сторонние интерфейсы api из остальной части вашего кода. На следующем шаге прочитайте, по крайней мере, книгу шаблонов GoF. Он описывает большинство шаблонов в понятном программном обеспечении.

+0

Спасибо. Фасад начинает казаться хорошей ставкой. – user277127

Смежные вопросы