Как правильно подобрать архетикуру (ООП) для задачи?

Question

[Никита Рощенко]

Не могу правильно подобрать архитектуру для задачи, пишу что-то наподобии агрегатора сайтов.

Есть модель Account c такими полями: login, password, provider_name

Есть класс Manager, в конструктор которого передается модель Account. В классе Manager есть метод getProvider(). Который инициализирует и возвращает объект класса Provider в соответствии со значением свойства provider_name в модели Account.

На каждый агрегируемый сайт есть свой класс Provider который может имплетировать интерфейсы например: ProfileInterface, MessageInterface, NewsInterface и т.д.

Интерфейсы описывают основные методы для работы с сайтом. Что бы можно было работать в цикле (при помощи конструкции instanceof) с разными сайтами не думая о том что происходит внутри класса Provider.

Так вот получается что когда класс Provider имплементирует несколько интерфейсов - то все хорошо, но когда количество имплементируеммых интерфейсов становится больше 5-10, то файл становится не читаемым, слишком много методов в классе Provider.

Допустим есть такие провайдеры:
Social/VK/Provider
Social/OK/Provider
Social/Facebook/Provider

Класс Manager получая в конструкторе объект Account по полю provider_name находит нужный Provider, например Social/VK/Provider и инициализирует его и возвращает объект Provider. То есть проводится авторизация на сайте Вконтакте в конструкторе класса Provider.

Дальше есть задача получить новости со всех аккаунтов:

foreach($accounts as $account) {
    $provider = Manager::getProvider($account);
    if ($provider instanceof NewsInterface) {
        $news = $provider->getNews();
        //...
    } else continue;
}

Я первым делом вспомнил про трейты, но дело в том что методы из разных интерфейсов могут использовать друг друга (например трейт описывающий реализацию интерфейса MessageInterface использует трейт описывающий реализацию интерфейса ProfileInterface). Да и почти в каждом трейте идет работа с БД коннект которого находится в свойстве объекта Provider.

В общем трейты работают, но не эстетически красиво. Я уверен что есть более красивая реализация, только не могу ее найти.

Заранее спасибо за любое замечание и предложение =)

Comments

[FoxInSox]

Вы бы хоть псевдокод какой-то набросали. Описывать архитектуру/код русским языком это издевательство.

Answer 1

[Алексей Уколов]

Что бы можно было работать в цикле (при помощи конструкции instanceof) с разными сайтами не думая о том что происходит внутри класса Provider.

Для этого существует полиморфизм. Instanceof - это антипаттерн.

По большому счету, замена трейтов - агрегация. Инжектите в конструкторе провайдера нужные обработчики и вызывайте уже их:

class FooProfileThing implements ProfileThingInterface {}

class FooMessageThing implements MessageThingInterface {}

class FooProvider extends Provider
{
  public function __constructor($bar)
  {
    $this->bar = $bar;
    $this->profileThing = new FooProfileThing;
    $this->messageThing = new FooMessageThing;
  }
}

Таким образом вы соблюдете принцип единственной ответственности и сможете более разумно построить иерархию этих объектов.

Да и вообще, что это за объекты Profile, Message, News, для которых вы создали интерфейс? Почему Provider одновременно ведет себя как профиль, сообщение и новость? Это сущности действительно однотипны?

Comments

[Никита Рощенко]

Почему Provider одновременно ведет себя как профиль, сообщение и новость? Это сущности действительно однотипны?

Provider в конструкторе принимает модель Account. Производит авторизацию в на сайте для которого написан этот провайдер. И хранит данные авторизации, коннект к БД и source_id (ID аккаунта на агрегируеммом сайте). На каждый сайт есть свой провайдер.

Допустим есть такие провайдеры:
Social/VK/Provider
Social/OK/Provider
Social/Facebook/Provider

Класс Manager получая в конструкторе объект Account по полю provider_name находит нужный Provider, например Social/VK/Provider и инициализирует его и возвращает объект Provider. То есть проводится авторизация на сайте Вконтакте в конструкторе класса Provider.

Дальше есть задача получить новости со всех аккаунтов:

foreach($accounts as $account) {
    $provider = Manager::getProvider($account);
    if ($provider instanceof NewsInterface) {
        $news = $provider->getNews();
        //...
    } else continue;
}

Вот как-то так сейчас происходит работа.

[Алексей Уколов]

В таком случае, провайдер - это просто фасад-агрегатор, внутри него должен быть authorizer, newsGrabber и т.п. Если все эти функции засунуть в него, то действительно, получится несвязная лапша.

Вот так будет лучше:

foreach($accounts as $account) {
    $provider = Manager::getProvider($account);
    if ($provider->hasNewsGrabber()) {
        $news = $provider->getNews();
        //...
    } else continue;
}

[Никита Рощенко]

Алексей Уколов: А код реализующий работу с новостями держать в отдельном классе и инициализировать его в конструкторе Provider?

Тогда получаем рассинхронизацию между разными Provider'ами, так как сам newsGrabber может различаться названием/наличием публичных методов.

А если мы каждый newsGrabber привяжем в интерфейсу NewsInterface то получаем все тоже самое что и с трейтами, только появляются методы (hasNewsGrabber) которые можно было бы заменить нативным instanceof.

В общем я пока не увидел преимущество вашего подхода. Сори если туплю, конец рабочего дня просто =)

[Алексей Уколов]

У вас провайдер предоставляет публичный интерфейс. Как и что он делает внутри - это его дело (именно поэтому, например, hasNewsGrabber лучше, чем instanceof).

Поэтому, если у newsGrabber'ов разных соц. сетей разный публичный интерфейс, это не страшно, ведь с каждым конкретным граббером работает конкретный провайдер, который об этом интерфейсе знает.

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

Преимущества подхода те же самые, что и у следования SOLID-принципам, потому что он именно их и реализует :)

[Alex Safonov]

Алексей Уколов: Никита Рощенко:
Я согласен с тем, что вы слишком перегрузили Provider. И прямо нарушаете SRP.
Разнесите авторизацию, коммуникацию, парсинг по разным сущностям. И унифицируйте работу спрятав всё за Facade.

Подход с полиморфизмом который вам предлагают - верен.