Разница между методами записи / статическими функциями с классами ES6 [duplicate]

Вы должны прочитать (если у вас есть доступ) Эффективный Java 2 Пункт 1: Рассмотрите статические заводские методы вместо конструкторов.

Преимущества статических заводских методов:

1. У них есть имена.
2. Они не обязаны создавать новый объект при каждом вызове.
3. Они могут возвращать объект любого подтипа своего возвращаемый тип.
4. Они уменьшают многословие создания экземпляров с параметризованным типом.

Недостатки статических заводских методов:

1. При предоставлении только статической фабрики методы, классы без публичных или защищенных конструкторов не могут быть подклассы.
2. Они не могут быть легко различимы с другими статическими методами

Спросите себя, кто они и почему у нас есть. Они оба существуют, чтобы создать экземпляр объекта.

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: Рассмотрите статические заводские методы вместо конструкторов, p. 5:

«Обратите внимание, что статический заводский метод не совпадает с шаблоном Factory Method из шаблонов проектирования [Gamma95, стр. 107]. Статический заводский метод, описанный в этом элементе, не имеет прямого эквивалента в Design Узоры ".

По умолчанию конструкторы должны быть предпочтительнее, потому что их проще понять и написать. Однако, если вам нужно отделить конструктивные тонкости объекта от его смыслового значения, понимаемого кодом клиента, вам будет лучше использовать фабрики.

Разница между конструкторами и фабриками аналогична , скажем, переменную и указатель на переменную. Существует еще один уровень косвенности, что является недостатком; но есть еще один уровень гибкости, что является преимуществом. Поэтому, делая выбор, вам было бы полезно провести анализ затрат и выгод.

Используйте фабрику только тогда, когда вам необходим дополнительный контроль с созданием объекта, что невозможно сделать с конструкторами.

У фабрик есть возможность кэширования, например.

Другой способ использования заводов - это сценарий, в котором вы не знаете тип, который хотите построить. Часто вы видите этот тип использования в сценариях фабрики плагинов, где каждый плагин должен получить базовый класс или реализовать какой-то интерфейс. Завод создает экземпляры классов, которые производятся из базового класса или реализуют интерфейс.

Иногда вам приходится проверять / вычислять некоторые значения / условия при создании объекта. И если он может выбросить исключение - constructro очень плохой способ. Поэтому вам нужно сделать что-то вроде этого:

var value = new Instance(1, 2).init()
public function init() {
    try {
        doSome()
    }
    catch (e) {
        soAnotherSome()
    }
}

Где все дополнительные вычисления находятся в init (). Но только вы, как разработчик, знаете об этом init (). И, конечно, после нескольких месяцев вы просто забыли об этом. Но если у вас есть фабрика - просто сделайте все, что вам нужно, одним способом, сокрыв этот init () от прямого вызова - поэтому проблем нет. При таком подходе нет проблем с падением на создание и утечкой памяти.

Кто-то рассказал вам о кешировании. Хорошо. Но вы также должны помнить о шаблоне Flyweight, который приятно использовать с фабричным способом.

Конкретный пример из приложения CAD / CAM.

Путь резания будет выполняться с помощью конструктора. Это серия линий и дуг, определяющих путь к разрезанию. Хотя ряд строк и дуг может быть разным и иметь разные координаты, он легко обрабатывается путем передачи списка в конструктор.

Форма будет производиться с использованием фабрики. Потому что, хотя есть класс формы, каждая фигура будет настраиваться по-разному в зависимости от того, какой тип формы он имеет. Мы не знаем, какую форму мы собираемся инициализировать, пока пользователь не сделает выбор.