Чистая архитектура для заметания мусора под коврик
Паттерны как средство защиты основной бизнес логики от изменений но часто изменения были желательны, а паттерны их осложнили и превратили в место для выноса сложности из бизнес логики в неподходящее место
**Сама по себе идея фабрики, как паттерна проектирования, потенциально провоцирует на нарушение принципа единственной ответственности (SRP), если применять её неаккуратно.
**Вот почему:
Соблазн "всё в одном месте": Фабрика концентрирует в себе логику создания объектов. Это может привести к соблазну добавлять туда всё больше и больше обязанностей, связанных с различными аспектами создания и инициализации объектов, включая обработку частных случаев.
Скрытие зависимостей: Фабрика может скрывать реальные зависимости создаваемых объектов. Вместо того, чтобы явно передавать зависимости через конструктор, разработчики могут начать внедрять их внутри фабрики, делая её более сложной и запутанной.
"Божественный объект": Если не следить за размером и ответственностью фабрики, она может легко превратиться в "божественный объект" (God Object), который знает слишком много и делает слишком много.
Трудности в тестировании: Раздутая фабрика, обремененная множеством обязанностей, становится сложной для тестирования в изоляции.
Однако, важно отметить, что сама по себе фабрика не является злом. Это полезный инструмент, который, при правильном использовании, может упростить код и сделать его более гибким.
Проблема возникает, когда:
Фабрика используется не по назначению: Например, для обработки частных случаев, которые должны решаться на уровне бизнес-логики.
Не соблюдается принцип единственной ответственности: Фабрике поручается слишком много обязанностей.
Чтобы избежать нарушения SRP при использовании фабрики, нужно:
Чётко определить её ответственность: Фабрика должна отвечать только за создание объектов, а не за их настройку, инициализацию или обработку специфических сценариев.
Ограничить её размер: Если фабрика становится слишком большой, её нужно разделить на несколько более мелких и специализированных фабрик.
Явно передавать зависимости: Зависимости создаваемых объектов должны передаваться через конструктор, а не внедряться внутри фабрики.
Использовать фабрику совместно с другими паттернами: Например, с внедрением зависимостей (Dependency Injection), чтобы сделать код более гибким и тестируемым.
Вывод:
Фабрика, как и любой другой паттерн проектирования, - это инструмент. Сама по себе она не хорошая и не плохая. Всё зависит от того, как её использовать. Если применять фабрику с умом и следить за соблюдением принципа единственной ответственности, она может быть очень полезной. В противном случае, она может привести к проблемам, о которых мы говорили.
когда я пишу код один я почти не использую паттерны проектирования, а только при коллективной работе как переборку от других программистов
но эта переборка не позволяет перетекать зависимостям, не менять чужой код
но часто эти изменения чужого кода были бы желательны, т.к. порождены им же самим