Полезен ли шаблон Factory вне каркаса без Visitor?

Question

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

Я не говорю, что фабричный шаблон не нужен. Например, интерфейс W3C Document служит фабрикой для различных узлов XML (элементов, атрибутов, текста, ...). Класс AST в Eclipse JDT служит фабрикой для ASTNode s, таких как Assignment, MethodDeclaration и т. Д. Я могу найти много других примеров фреймворка / библиотеки.

Но большую часть времени в простом клиентском коде я никогда не чувствую необходимости использовать шаблон Factory. Вам все равно, откуда берутся объекты или как они создаются. Вы просто подключаете объекты через их интерфейсы с помощью Dependency Injection, после чего эти объекты могут «ожить» в зависимости от среды (например, new вручную в простом локальном тесте, контейнер компонентов в среде Java EE, .. .). Но никогда Фабрикой, как ArticleFactory.createArticle().

Я понимаю, что Spring, например, можно считать «фабрикой» бинов, но фабрика бинов Spring очень универсальна, и реализация Factory, о которой я говорю, должна иметь определенный интерфейс и каким-то образом ограничиваться созданием члены предопределенного «семейства» объектов.

Я также заметил, что Factory, Composite и Visitor часто идут рука об руку, когда Factory создает набор (связанных с доменом) объектов, которые Visitor может пройти. Опять же, типичные вещи для фреймворков, но не клиентский код.

Поэтому мой вопрос: существуют ли ситуации вне рамок, где вы (будете) использовать шаблон Factory вместо простых интерфейсов и внедрения зависимостей? И если да, есть ли связанный посетитель?

Answer 1

Я использую Фабричные классы (или методы) с некоторой регулярностью. Возможно, это признак антипаттерна Золотого Молота , как Фабрика, является одним из паттернов, которые я хорошо понимаю, но я нашел применение. Одно из применений, которое я недавно обнаружил, - это внедрение Factory для создания LINQ DataContexts по мере необходимости для единиц работы в контроллерах ASP.NET MVC. Используя Factory, методы в контроллере могут использовать методы Factory для создания нового DataContext по требованию. В сочетании с внедрением зависимостей это дает мне возможность как смоделировать Фабрику (и, следовательно, DataContext), так и создание по требованию.

Answer 2

Как говорит Максим Ройллер в этом посте, я бы хотел, чтобы больше людей ЖДЕЛО, пока им действительно не понадобится создавать различные виды объектов, прежде чем они реализуют фабрику. Могу поспорить, что в большинстве случаев необходимость никогда не будет реализована, и фабрика не будет необходимости.

http://blog.decayingcode.com/post/anti-pattern-gas-factory-or-unnecessary.aspx

Answer 3

Возможно, конкретный пример поможет.

В моем программном обеспечении CAD / CAM у меня есть каталог DLL, каждая из которых имеет различное количество параметрических фигур. Все фигуры реализуют интерфейс IParametricShape. Каждая DLL имеет класс Factory, который имеет единственный метод, который возвращает коллекцию IParametricShape. Это добавляется в основной список программного обеспечения и становится доступным для пользователя.

Программное обеспечение CAD / CAM довольно специфично для моей отрасли, так как мы также используем его для типов файлов и отчетов. Которые используются многими другими типами программного обеспечения. У вас есть список отчетов, каждый из которых реализует интерфейс IReport. У вас есть фабрика, возвращающая коллекцию IReports. Вы добавляете это в свой основной список отчетов и делаете его доступным для пользователя. Изменяя DLL и класс Factory, вы можете изменять коллекцию и легко добавлять новые отчеты. То же самое с типом файлов, с которыми вы работаете.

Наконец, вы можете иметь свойства интерфейса, которые позволят вам определить, какой отчет (или тип файла) находится в вашем программном обеспечении. Например, у меня есть коллекция отчетов по стандартам магазинов, в которой есть отчеты для распечатки параметров настройки клиентов. Другой сборник отчетов, относящихся к работе, с которой имеет дело клиент. Свойство говорит мне, какой отчет какой. В качестве альтернативы вы можете использовать два отдельных фабричных метода, один для производства Коллекции A, а другой для Коллекции продуктов B.

Answer 4

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

Пример:

Допустим, вы настраиваете веб-службу через DI и что эта веб-служба использует прокси для связи с другими веб-службами.

Эти прокси должны быть закрыты / удалены очень часто, и они должны быть короче, чем веб-сервис. Вместо внедрения веб-службы с прокси-сервером (что приведет к тому, что срок службы прокси-сервера будет привязан к веб-службе, т. Е. Его нельзя будет закрыть, пока веб-служба его использует), вы бы добавили его через интерфейс IProxyFactory.

таким образом, веб-служба может запросить интерфейс IProxyfactory для создания реализации IProxy, для которой она может делегировать вызов другой службе. веб-сервис может закрывать / утилизировать прокси-сервер каждый раз, когда он его использует.