Как создать экземпляр класса в фабричном методе?

Question

[ragnar_ok]

Пытаюсь реализовать паттерн "Простая фабрика" (в моем случае фабрика компонентов). Как принято создать экземпляр класса в фабричном методе: switch, reflection или?..

При использовании reflection фабричный метод (в примере ComponentFactory::createInstance) будет возвращать тип object, а не интерфейс (ComponentInterface), что, кажется плохим.

switch выглядит неплохо за исключением одной проблемы. Допустим, завтра мы хотим добавить еще одну реализацию. Нам нужно будет изменить этот код и добавить новый case. В перспективе количество case в ComponentFactory::createInstance может стать неприлично большим.

interface ComponentInterface
{
    public function getName(): string;
}
 
class NewsComponent implements ComponentInterface
{
    public function getName(): string
    {
        return 'news';
    }
}
 
class ComponentFactory
{
    public function createInstance($component): ?ComponentInterface
    {
        $instance = null;
        switch ($component) {
            case 'news':
                $instance = new NewsComponent();
                break;
        }
        
        return $instance;
    }
 
    public function createInstance($component)
    {
        if (!class_exists($component)) {
            throw new ClassNotFoundException();
        }
 
        $reflectionClass = new ReflectionClass($component);
        return $reflectionClass->newInstance();
    }
}

// клиентский код
$componentFactory = new ComponentFactory();
$component = $componentFactory->createInstance('news');

Comments

[Александр]

Можно упростить гораздо. Без swith. Просто создавай new "{$component}Component". Можешь даже почитать https://refactoring.guru/ru/smells/switch-statements. Раздел лечение, второй пункт. Первый вариант ничем не отличается от второго. Только добавить проверку на существование, и то можно сделать на уровне выше, в автозагрузчике.

public function createInstance($component): ComponentInterface
    {
        return new "{$component}Component";
    }

[Александр]

Так же, если нету компонента, не нужно возвращать null. Создай для этого случая исключение и выбрасывай.

[BoShurik]

Вы описали не Простую фабрику, а Статичную фабрику

[Александр]

BoShurik, собственно я описал ваш пример. У вас как раз такой и приведен

[BoShurik]

Александр, автор упоминает простую фабрику, а код от статичной

[Александр]

BoShurik, вы путаете простую фабрику от статичной. Как минимум в статичной есть статический метод. Который и будет генерировать новые обьекты. Собственно там так и написано. Простая фабрика - Она отличается от Статической Фабрики тем, что собственно не является статической

[BoShurik]

Александр, возможно. Не силен в терминологии. Думал что простая фабрика это вот:

Тык

interface ComponentInterface
{
    public function getName(): string;
}

class NewsComponent implements ComponentInterface
{
    public function getName(): string
    {
        return 'news';
    }
}

class ArticleComponent implements ComponentInterface
{
    public function getName(): string
    {
        return 'article';
    }
}

interface ComponentFactoryInterface
{
    public function create(): ComponentInterface;
}

class NewsComponentFactory implements ComponentFactoryInterface
{
    public function create(): ComponentInterface
    {
        return new NewsComponent();
    }
}

class ArticleComponentFactory implements ComponentFactoryInterface
{
    public function create(): ComponentInterface
    {
        return new ArticleComponent();
    }
}

class ComponentFactory
{
    /**
     * @param array<string, ComponentFactoryInterface> $factories
     */
    public function __construct(private array $factories)
    {
    }

    public function create(string $name): ComponentInterface
    {
        return $this->factories[$name]->create();
    }
}

$factory = new ComponentFactory([
    'news' => new NewsComponentFactory(),
    'article' => new ArticleComponentFactory(),
]);

var_dump($factory->create('news')->getName());

Или это тоже простая фабрика?

[Александр]

BoShurik, Вот это проста фабрика. А в конце кода фабричный метод

class NewsComponentFactory implements ComponentFactoryInterface
{
    public function create(): ComponentInterface
    {
        return new NewsComponent();
    }

[ragnar_ok]

Александр, спасибо! Очень помог! Для окончательного понимания:
1. BoShurik привел в примере паттерн "Фабричный метод", так? Мне кажется, что для моего случая он избыточен.
2. Мой пример и есть паттерн "Простая фабрика"?

[BoShurik]

ragnar_ok, в примерах, что у вас - возможно. Но если представить, что вашим компонентам нужны зависимости, то вариант со switch не подойдет

Answer 1

[vitaly_74]

1. case сам по себе не есть плохо, и это не считается дурным тоном. т.е. использовать конструкцию case можно и нужно.
2. Давайте подумает чем характеризуется объект экземпляра класса, а потом перейдем к фабрике.
Объект прежде всего характеризуется данными хранящимися внутри него. Т.е. Фабрика должна внутри себя хранить то что она выпускает (строит) и всю информацию о нем.
3. не используйте рефлекшен. это плохо это дурной код, без крайней необходимости не нужно. Обычно рефлекшены не используются в клиентском коде, только непосредственно в самих фреймворках. но раз вы задаете вопросы про фабрики, вы фреймворк не пишите, а значит и использование рефлекшенов вам не нужно.
4. Взгляните на оператор new (например, new Factory()) по сути оператор new и есть фабрика, которая из класса создает объект с уникальными (а может и не всегда) наборами данных.
5. в ссылке выше, вам дали информацию по рефакторингу switch но если прочитать там, написано,
не стоит трогать если

Зачастую оператор switch используется в фабричных паттернах проектирования (Фабричный метод, Абстрактная фабрика) для выбора создаваемого класса

вот в данном случае не нужно трогать.
Почему лучше использовать switch?
- потому что когда через год, или два зайдете в эту фабрику, навряд ли вы захотите разбираться в рефлекшенах, и не интуитивных выражениях. А когда все есть в switch вы сразу увидите перед глазами какие объекты может выпускать фабрика + по аналогии создать подобный объект используя менее трудозатрат (почти копипаст).
Вот тут хороший пример фабрики:
https://refactoring.guru/ru/design-patterns/factor...
или можно так:

/**
 * Интерфейс Продукта объявляет операции, которые должны выполнять все
 * конкретные продукты.
 */
interface Product
{
    public function operation(): string;
}

/**
 * Конкретные Продукты предоставляют различные реализации интерфейса Продукта.
 */
class ConcreteProduct1 implements Product
{
    public function operation(): string
    {
        return "{Result of the ConcreteProduct1}";
    }
}

class ConcreteProduct2 implements Product
{
    public function operation(): string
    {
        return "{Result of the ConcreteProduct2}";
    }
}

class Factory implements Product{
   private $product;
   function __construct(string $productClass){
       switch($productClass){
           case default:
           case ConcreteProduct1::class:
                      $product = new ConcreteProduct1();
           break;
           case ConcreateProduct2::class:
                      $product = new ConcreateProduct2();
           break;
       }
       $this->product = $product;
   }

   public function operation(): string
    {
        return $this->product->operation();
    }
}

$product = new Factory(ConcreateProduct1::class);
echo $product->operation();

В данном случае Разрешено менять старый код, но только в пределах switch.

Comments

[Александр]

Могу с уверенностью сказать, что для однотипной фабрики не стоит использовать switch !В его случае именно такая. Все типы это Компоненты наследованные от общего интерфейса. Дурной том в такой случае использовать switch. Если был фабричный метод, ок согласен. Но не тут.

[vitaly_74]

Александр, почему дурной тон? привидите пожалуйста пример для однотипной фабрики, как сделали бы вы.

[ragnar_ok]

vitaly_74, спасибо! Дополнил ваш пример. Добавил \Product::getName в интерфейс. Этот метод должен возвращать одно и то же значение для нескольких конкретных продуктов, поэтому добавил также абстрактный класс BaseProduct. Подходит ли такая реализация?

Здесь достаточно паттерна"Простая фабрика" или уже нужно использовать "Фабричный метод"?

interface Product
{
    public function getName(): string;
    public function operation(): string;
}

abstract class BaseProduct implements Product
{
    public function getName(): string
    {
        return 'some_product1';
    }
}

class ConcreteProduct1 extends BaseProduct
{
    public function operation(): string
    {
        return "{Result of the ConcreteProduct1}";
    }
}

class ConcreteProduct2 extends BaseProduct
{
    public function operation(): string
    {
        return "{Result of the ConcreteProduct2}";
    }
}

[vitaly_74]

ragnar_ok, вообще пользуюсь определениями "фабрика" и "абстрактная фабрика" у вас в вопросе "фабрика". в вашем примере не хватает класса самой фабрики. а так да можно и так. если getName() возвращает одно и тоже. Но опять же, аккуратней с наследованиями (в том плане, что вы можете в будущем запутаться в них)

[BoShurik]

vitaly_74, фабрика через new - спорное решение.
- ее нельзя использовать через DI
- при наличие зависимостей придется и их прокидывать (в моих проектах 90% фабрик имеют зависимости)
- созданный объект в итоге скрыт от пользователя, т.е. проверки вида $product instanceof ConcreateProduct1 не доступны. Получается что-то типа фабрика + прокси.
А в чем плюсы?

[vitaly_74]

BoShurik,
у нас с вами разные стили программирования. Например, в своих проектах я никогда не использую DI т.к. считаю это вредным.
например, зачем в коде вот это: $product instanceof ConcreateProduct1 ? вы пишите бизнес логику или фреймворки? если бизнес логику, то насколько я понимаю вы не оперируете сущностями. а их именами, но допустим это за уши притянуто.
Зависимости - разве это плохо? Когда вы в клиентском коде пишите абстрактный DI и не понимаете что он делает. или когда в коде видно что откуда и зачем берется. я так и не увидел вашего примера, к сожалению.

[BoShurik]

Вот несколько расширенный пример автора. Как мне кажется больше приближен к реальности за счет того, что используются зависимости. Плюс минус с такими фабриками в итоге и приходится иметь дело

interface ComponentInterface
{
    public function getName(): string;
    public function getItems(): iterable;
}

class NewsComponent implements ComponentInterface
{
    public function __construct(private NewsRepository $repository)
    {
    }

    public function getName(): string
    {
        return 'news';
    }

    public function getItems(): iterable
    {
        return $this->repository->findAll();
    }
}

class ArticleComponent implements ComponentInterface
{
    public function __construct(private ArticleRepository $repository)
    {
    }
    
    public function getName(): string
    {
        return 'article';
    }

    public function getItems(): iterable
    {
        return $this->repository->findAll();
    }
}

interface ComponentFactoryInterface
{
    public function create(): ComponentInterface;
}

class NewsComponentFactory implements ComponentFactoryInterface
{
    public function __construct(private NewsRepository $repository)
    {
    }

    public function create(): ComponentInterface
    {
        return new NewsComponent($this->repository);
    }
}

class ArticleComponentFactory implements ComponentFactoryInterface
{
    public function __construct(private ArticleRepository $repository)
    {
    }

    public function create(): ComponentInterface
    {
        return new ArticleComponent($this->repository);
    }
}

class ComponentFactory
{
    /**
     * @param array<string, ComponentFactoryInterface> $factories
     */
    public function __construct(private array $factories)
    {
    }

    public function create(string $name): ComponentInterface
    {
        return $this->factories[$name]->create();
    }
}

$factory = new ComponentFactory([
    'news' => new NewsComponentFactory(new NewsRepository($entityManager, News::class)),
    'article' => new ArticleComponentFactory(new ArticleRepository($entityManager, Article::class)),
]);

var_dump($factory->create('news')->getName());

С помощью DI переменная $factory инициализируется без необходимости прописывать весь граф зависимостей (а он в реальности может быть очень большим). Не понимаю в чем его вредность.

Зависимости - разве это плохо?

Как раз наоборот. Без них никуда. Как с вашим подходом их пробрасывать в продукты?

Ну и вы так и не ответили на вопрос. В чем плюсы совмещения фабрики и прокси?