Как организовать фабрику?

Question

[Михаил]

В приложении такая структура:

Component\service\CatalogProductRepository
Component\domain\CatalogProductRepositoryInterface
Component\cache\CatalogProductRepositoryCache

Возникла проблема с использованием этого компонента. В данный момент для инициализации нужно выполить:

$baseModel = new Component\service\CatalogProductRepository;
$cache  = new Component\Cache;
$model = new Component\cache\CatalogProductRepositoryCache($baseModel, $cache);

Пришла идея использовать фабрику, но как ее правильно сделать - не ясно. Я вижу 2 варианта:
1. Component\factory\CatalogProductRepositoryFactory.

$model = CatalogProductRepositoryFactory::create(true); // create($useCache = false)

Но для каждой сущности придется создавать свою фабрику.
2. Component\Factory.

$model = Factory::create('CatalogProductRepository', true); // create($model, $useCache = false)

Что лучше?

p.s. идея от Сергей Протько

Answer 1

[Сергей Протько]

Может ну его? Реально? Попробуйте прочитать этот код кому-нибудь, он же не читается. Понятия не имею почему вы решили назвать репозиторий для продукта CatalogProductRepository. Или зачем вам фабрика. Ну и еще - зачем вы инстанцируете все руками. И что это за true.

Оба варианта как по мне изобилуют излишней сложностью, неочевидны и т.д. и т.п.

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

Моя "идея" заключалась лишь в использовании декоратора для реализации логики кеширования. Суть идеи простая - что бы добавить кеширование не нужно ничего править ни в логике использующую репозиторий, ни в самом репозитории.

Comments

[Михаил]

Воу-воу) Итак.
> почему вы решили назвать репозиторий для продукта CatalogProductRepository.
CatalogProductRepository
продукта репозиторий

Вообще, в моем случае CatalogProductRepository ассоциация к сущности в API. Она там так и называетя.

На счет DependencyInjection.
Проблемы 2:
1. Нужно покопаться есть ли к yii2 эта штука и как реализовывается.
2. Если я правильно понял принцип, то в случае с DependencyInjection я не смогу вызвать в одном случае вызвать метод с кэшированием, а в другом - без.

Собственно, поэтому выходом является фабрика
> И что это за true
с флагом для возврата модели с кэшированием или без.

[Сергей Протько]

Михаил: есть в Yii2 dependency injection, они ее из laravel попытались стащить.

www.yiiframework.com/doc-2.0/guide-concept-di-cont...

[Сергей Протько]

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

Учитесь разделять ответсвенность ваших объектов.

[Михаил]

Сергей Протько: хорошо, решил попробовать di, но столкнулся с тем что базовый класс не требует ничего в конструкте, а кэширующий требует этот базовый класс. Как тогда назначить зависимость?

из доки пример не показывает как передать параметры в BookingService
\Yii::$container->set('app\components\BookingInterface', 'app\components\BookingService');

[Сергей Протько]

Михаил: так это ж не наследование, два разных класса

[Михаил]

Сергей Протько: не наследование. Т.е. нужно для каждого базового класса создать кэширующий класс с теми же методами, даже если кэширование не требуется?

может быть наследование будет более универсально.

[Сергей Протько]

Михаил: если вам не нужно кеширование - вы не делаете декоратор. Логично же. Ну а нужно - делаете.

Вся проблема в том видимо что в моих "классах" один-два публичных метода, а у вас видимо десяток.

[Михаил]

Сергей Протько:
> если вам не нужно кеширование - вы не делаете декоратор.
сейчас так и есть, временно.

В ответе вы написали
> Я предлагаю вам вооружиться DependencyInjection
я пытаюсь понять как в данном случае можно его использовать, но не понятно. Что вы имели ввиду?

> у вас видимо десяток
да нет, пару-тройку.

[Сергей Протько]

Михаил: dependency injection - это для того что бы рулить зависимостями и не писать руками фабрики.

Декораторы - это декораторы. Вы пишите их только тогда когда они нужны. Они нужны что бы "добавлять" повезение объектам не меняя их и не нарушая принцип единой ответственности. Это позволяет уменьшить количество причин по которым вам захочется поменять ваш код. (маленькие вещи менять проще, а еще с маленькими штуками старые можно выкинуть и написать новые, и это будет быстрее чем править жирную хрень)

[Михаил]

Сергей Протько: Ясно.

Столкнулся с тем что не получится скомбинировать логику с кэшированием. То, что кэш работает уровнем выше приносит плюс в виде понятной архитектуры, но, например, нельзя вызвать methodA() который бы вызывал кэшированный methodB(), поскольку они ниже уровня кэша. MethodB(), например, быстро устаревает и кэшировать его нет смысла.

Постоянно думаю на счет использования наследования, адекватно ли это?