Конструкторы по сравнению с [закрытыми] методами фабрики
Вы можете перебрать коллекцию HTML, используя Array.prototype.filter, вызываемую с коллекцией HTML в качестве контекста.
Следующий фрагмент может быть полезным:
var cells = document.getElementById("calendar-dates").getElementsByTagName("td");
var current_date = d.getDate();
var matchingElement = Array.prototype.filter.call(cells, function(cell) {
return +current_date === +cell.textContent;
})[0];
matchingElement.style.backgroundColor = 'red';
6 ответов
Использование Шаблон "фабричный метод", когда
- класс не может ожидать класс объектов, он должен создать
- , класс хочет, чтобы его подклассы определили объекты, которые это создает
- , классы делегируют ответственность перед одним из нескольких подклассов помощника, и Вы хотите локализовать знание, которого подкласс помощника является делегатом
Спросите себя, что они и почему делают у нас есть они. Они оба там для создания экземпляра объекта.
ElementarySchool school = new ElementarySchool();
ElementarySchool school = SchoolFactory.Construct(); // new ElementarySchool() inside
Никакое различие до сих пор. Теперь предположите, что у нас есть различные школьные типы, и мы хотим переключиться от использования ElementarySchool к HighSchool (который получен из ElementarySchool или реализует тот же интерфейс ISchool как ElementarySchool). Изменение кода было бы:
HighSchool school = new HighSchool();
HighSchool school = SchoolFactory.Construct(); // new HighSchool() inside
В случае интерфейса мы имели бы:
ISchool school = new HighSchool();
ISchool school = SchoolFactory.Construct(); // new HighSchool() inside
Теперь, если у Вас есть этот код в нескольких местах, Вы видите, что использование метода фабрики могло бы быть довольно дешевым потому что, как только Вы изменяете метод фабрики, Вы сделаны (если мы используем второй пример с интерфейсами).
И это - основное различие и преимущество. Когда Вы начинаете иметь дело со сложные иерархии классов, и Вы хотите динамично создать экземпляр класса от такой иерархии, Вы получаете следующий код. Методы фабрики могли бы тогда взять параметр, который говорит метод что конкретного экземпляра инстанцировать. Скажем, у Вас есть класс MyStudent, и необходимо инстанцировать соответствующего объекта ISchool так, чтобы студент был членом той школы.
ISchool school = SchoolFactory.ConstructForStudent(myStudent);
Теперь у Вас есть одно место в Вашем приложении, которое содержит бизнес-логику, которая определяет то, чему ISchool возражают для инстанцирования для различных объектов IStudent.
Так - для простых классов (объекты значения, и т.д.) конструктор очень хорошо (Вы не хотите сверхпроектировать свое приложение), но для сложных иерархий классов метод фабрики является предпочтительным путем.
Этот путь Вы следуете за первым принципом разработки от банда четырех книг "Программа к интерфейсу, не реализация".
Необходимо читать (если у Вас есть доступ к) Эффективный объект Java 2 1: Рассмотрите статические методы фабрики вместо конструкторов .
Статические преимущества методов фабрики:
- у Них есть имена.
- Они не обязаны создавать новый объект каждый раз, когда они вызываются.
- Они могут возвратить объект любого подтипа их типа возврата.
- Они уменьшают многословие создания параметризованных экземпляров типа.
Статические недостатки методов фабрики:
- При обеспечении только статических методов фабрики, классы без общедоступных или защищенных конструкторов не могут быть разделены на подклассы.
- Они не с готовностью различимы от других статических методов
По умолчанию конструкторы должны быть предпочтены, потому что они более просты понять и записать. Однако, если конкретно необходимо разъединить тонкости конструкции объекта от его семантического значения, как понято под клиентским кодом, Вы были бы более обеспеченными фабриками использования.
различие между конструкторами и фабриками походит, скажем, на переменную и указатель на переменную. Существует другой уровень абстракции, который является недостатком; но существует другой уровень гибкости также, которая является преимуществом. Таким образом, при совершении выбора, Вам было бы целесообразно сделать эту стоимость по сравнению с анализом прибыли.
Используйте фабрику только при необходимости в дополнительном управлении с созданием объекта, способом который не мог быть сделан с конструкторами.
Фабрики имеют возможность кэширования, например.
Другой способ использовать фабрики находится в сценарии, где Вы не знаете тип, Вы хотите создать. Часто Вы видите этот тип использования в сменных сценариях фабрики, где каждый плагин должен произойти из базового класса или реализовать некоторый интерфейс. Фабрика создает экземпляры классов, которые получают из базового класса или той реализации интерфейс.
Конкретный пример из приложения CAD/CAM.
путь вырезания А был бы сделан при помощи конструктора. Это - серия строк и дуг, определяющих путь к сокращению. В то время как серии строк и дуг могут отличаться и иметь различные координаты это легко обработанный путем передачи списка в конструктора.
форма А была бы, будет сделан при помощи фабрики. Поскольку, в то время как существует класс формы, каждая форма была бы установкой по-другому в зависимости от того, какая форма это. Мы не знаем то, что формирует, мы собираемся быть инициализацией, пока пользователь не делает выбор.