Как правильно подобрать архетикуру (ООП) для задачи? Не могу правильно подобрать архитектуру для задачи, пишу что-то наподобии агрегатора сайтов.
Есть модель 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/ProviderSocial/OK/ProviderSocial/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.
В общем трейты работают, но не эстетически красиво. Я уверен что есть более красивая реализация, только не могу ее найти.
Заранее спасибо за любое замечание и предложение =)
Как правильно подобрать архетикуру (ООП) для задачи? Не могу правильно подобрать архитектуру для задачи, пишу что-то наподобии агрегатора сайтов.
Есть модель 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/ProviderSocial/OK/ProviderSocial/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.
В общем трейты работают, но не эстетически красиво. Я уверен что есть более красивая реализация, только не могу ее найти.
Заранее спасибо за любое замечание и предложение =)
Есть модель 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/ProviderSocial/OK/ProviderSocial/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.
В общем трейты работают, но не эстетически красиво. Я уверен что есть более красивая реализация, только не могу ее найти.
Заранее спасибо за любое замечание и предложение =)
Не можешь разобраться в этой теме?
Обратись за помощью к экспертам
Гарантированные бесплатные доработки в течение 1 года
Быстрое выполнение от 2 часов
Проверка работы на плагиат
Поможем написать учебную работу
Для данной задачи можно использовать паттерн проектирования "Фасад". В этом случае вы можете создать класс-фасад, который будет объединять все необходимые операции для работы с различными провайдерами.
Вы можете создать отдельные классы для каждого провайдера и интерфейсов, которые они имплементируют. Затем в классе-фасаде вы можете реализовать методы для работы с каждым провайдером, вызывая нужные методы из соответствующего класса провайдера.
Это позволит разделить логику работы с разными провайдерами на отдельные классы, сделает структуру более читаемой и понятной, а также обеспечит легкость расширения, если в будущем потребуется добавить новые провайдеры или функционал.
Также, вы можете использовать инверсию управления (Dependency Injection), чтобы предоставлять экземпляры провайдеров в класс Manager через конструктор или методы, вместо создания их внутри класса Manager. Это упростит тестирование кода и сделает его более гибким.
Надеюсь, эти советы помогут вам выбрать более подходящую архитектуру для вашего проекта.