Когда использовать Шаблон "фабричный метод"?
Константы являются просто нижними индексами с пустым прототипом, таким образом, они могут быть экспортированы как любая другая замена
# file Foo.pm
package Foo;
use constant BAR => 123;
use Exporter qw(import);
our @EXPORT_OK = qw(BAR);
# file main.pl:
use Foo qw(BAR);
print BAR;
7 ответов
Хотя это не обязательно основное использование, это хорошо для тех случаев, когда у вас есть специализированные экземпляры класса:
public ITax BuildNewSalesTax()
public ITax BuildNewValueAddedTax()
Вам нужны оба метода для создания объекта налога, но вы этого не сделаете. Я не хочу зависеть от использования «нового» каждый раз, потому что конструкторы могут быть сложными. Таким образом, я инкапсулирую все изменения в один метод, понятный другим для дальнейшего обслуживания.
У меня есть два случая, когда я использую его:
- Объект должен быть инициализирован определенным образом
- Когда я хочу построить определенный тип на основе абстрактного типа (абстрактный класс или интерфейс).
Примеры:
Первый случай может заключаться в том, что вы хотите иметь фабрику, создающую объекты
SqlCommand, к которым вы автоматически присоединяете действительныйSqlConnectionперед возвратом объекта команды.Второй случай - если у вас есть определенный интерфейс и во время выполнения вы определяете, какую точную реализацию интерфейса использовать (например, указав ее в файле конфигурации).
Вы можете обратиться к разделу 9.5 «Фабрики» из 2-го издания Руководства по проектированию инфраструктуры. Вот процитированный набор рекомендаций относительно использования фабрик вместо конструкторов:
ДЕЙСТВИТЕЛЬНО предпочитаю конструкторы фабрики, потому что они в целом более удобный, последовательный, и удобнее, чем специализированное строительные механизмы.
РАССМАТРИВАЙТЕ использование фабрики, если вам нужно больше контроля, чем может дать конструкторы над созданием
ОБЯЗАТЕЛЬНО используйте фабрику в случаях, когда разработчик может не знать, какой тип построить, например, при кодировании против базового типа или интерфейса.
РАССМАТРИВАЙТЕ использование фабрики, если у вас есть именованный метод - единственный способ сделать операция не требует пояснений.
ДЕЙСТВИТЕЛЬНО используйте фабрику для преобразования стиля операций.
И из раздела 5.3 Дизайн конструктора
РАССМАТРИВАЙТЕ использование статического фабричного метода вместо конструктора, если семантика желаемой операции не отображается напрямую на конструкцию создание нового экземпляра или при соблюдении рекомендаций по проектированию конструктора кажется неестественным.
Используйте шаблон абстрактной фабрики, когда система не должна зависеть от того, как создаются, составляются и представляются ее продукты. система должна быть сконфигурирована с использованием одного из нескольких семейств продуктов. семейство связанных объектов продукта разработано для совместного использования, и вам необходимо обеспечить соблюдение этого ограничения. вы хотите предоставить библиотеку классов продуктов, и вы хотите раскрыть только их интерфейсы, а не их реализации.
Чтобы ответить на вторую часть вашего вопроса, с моей точки зрения, я думаю, что причина, по которой это лучше, чем ключевое слово 'new', заключается в том, что фабричный метод снижает зависимость от конструкторов определенных классов. Используя фабричный метод, вы делегируете создание рассматриваемого объекта кому-то другому, поэтому вызывающей стороне не нужно знать, как создать объект.
Лучше иметь шаблон фабричного метода вместо нового ключевого слова. Идея состоит в том, чтобы вывести полное создание объектов за пределы бизнес-логики. Этот принцип составляет основу внедрения зависимостей . Кроме того, позже работа фабричного метода может быть делегирована инфраструктуре внедрения зависимостей, такой как Spring.net или Castle Windsor.
Идея состоит в том, чтобы вывести полное создание объектов за пределы бизнес-логики. Этот принцип составляет основу внедрения зависимостей . И работа фабричного метода может быть позже делегирована инфраструктуре внедрения зависимостей, такой как Spring.net или Castle Windsor. Идея состоит в том, чтобы вывести полное создание объектов за пределы бизнес-логики. Этот принцип составляет основу внедрения зависимостей . И работа фабричного метода может быть позже делегирована инфраструктуре внедрения зависимостей, такой как Spring.net или Castle Windsor.Я думаю, это когда вы хотите, чтобы ваше приложение было слабосвязанным и расширяемым в будущем без изменений в коде.
Я написал в блоге сообщение о том, почему я выбираю шаблон фабрики в своем проекте, и, возможно, он может дать вам больше информации. Пример приведен на PHP, но я думаю, что он применим в целом ко всем языкам.
http://www.mixedwaves.com/2009/02/implementing-factory-design-pattern/