Статичний стан поганий, але як бути з заводською схемою?

Я працюю над проектом TDD, тому намагаюся якомога більше дотримуватися добрих стосунків, пов'язаних із таким розвитком. Один з них - максимально уникати статичного та глобального.

Я зіткнувся з цією проблемою: у мене об’єкт "стаття", який може мати "параметри" (додаткові "мікро-статті").

Я не можу зрозуміти, як мати хороший підхід, який не буде контрпродуктивним або генерувати надто багато запитів, тому що я опинився б у ситуації, коли все настільки нерозривно, що мені в основному потрібно робити 1 запит на об'єкт.

З моєї реальної точки зору, я бачу 3 варіанти:

1) Побудувати всередині статті:

class Article
{
    //[...]
    public function getArrOption(){
        //Build an array of Options instance.
        //return an array of Options.
    }
}

Pro: Прямо вперед

Const: Maintenability: Об'єкт статті тепер містить логіку побудови об’єкта Option. Це, ймовірно, призведе до дублювання коду.

2) Використання параметраFactory

class Article
{
    //[...]
    public function getArrOption(){
        return OptionFactory::buildFromArticleId($this->getId());
    }
}

Про: Логіка побудови не виходить із класу Article

Конст: Я порушую правило "статичного важко знущатися", тому важко перевіряю клас статті.

3) Відокремте всі логіки.

//Build the array of Option instance in a controller somewhere, using a Factory:
$arrOption = OptionFactory::buildFromArticleId($article->getId());

Про: Стаття поводиться лише з власною відповідальністю, і це не стосується його "батькового" посилання на варіанти. Речі справді розв'язані

Const: Буде потрібно більше коду всередині контролера щоразу, коли мені потрібно буде отримати доступ до параметрів. Це означає, що я ніколи не повинен використовувати Фабрику всередині предмета, і це звучить для мене щось утопічне ...

Який найкращий шлях? (Я щось пропустив?) Дякую.

Редагувати:

Не кажучи вже про те, що якщо я не можу викликати фабрику всередині класу, я в принципі ніколи не використовую ледачий шаблон ініціалізації ...

1. Статична статистика не є "поганою", вона неможлива. Ви все ще можете використовувати його там, де глузувати не має сенсу.

2. Це не заводський зразок, він схожий на шаблон сховища, хоча може і не бути. Завод - це те, де у вас є кілька класів з одним інтерфейсом / базовим класом, і ви хочете відокремити логіку, яка вирішує, який клас повернути. Репозиторій отримує дані зі свого сховища, обмежуючи реалізацію цього сховища (Статтю не потрібно знати, чи зберігаються його параметри в одній БД, в іншій, XML-файлі, у файлі CSV тощо).

3. Ви проігнорували можливість надання класу Article об’єкту ObjectFactory (або репозиторію чи будь-якого іншого) в конструкторі, на якому він може викликати метод buildFromArticle.

Мій PHP іржавий, але я думаю, що це виглядає приблизно так:

class Article
{
    private $_option_repository;

    public function __construct($option_repository) {
        $_option_repository = $option_repository;
    }

    //[...]

    public function getArrOption(){
        return $_option_repository->buildFromArticleId($this->getId());
    }
}

Я думаю, що це відповідає всім вашим плюсам вище.

Ось цитата з документа, яка стверджує, що статичні методи ніколи не потрібні, що абстрактні фабрики були заплутані, і передбачає незначну зміну мови у напрямку введення залежності як рішення.

Жорстке з'єднання між екземплярами та їхніми класами порушує інкапсуляцію, а разом із глобальною видимістю статичних методів ускладнює тестування. Зробивши введення функції залежності в мову програмування, ми можемо повністю позбутися статичних методів. Ми застосовуємо наступні смислові зміни:

(1) замінювати кожне виникнення глобальної інформації на доступ до змінної екземпляра;

(2) Нехай ця змінна інстанція буде автоматично введена в об'єкт, коли вона створена.

"Seuss: Розв'язування обов'язків від статичних методів для тонкої зернистості"

Wayback Machine Link