Преимущества FactoryMethod
Преимущество фабричного метода я вижу в том что клиент передает объект с фабричным методом без создания объекта который создает фабричный метод, таким образом мы не создаем если не надо и с другой стороны можем себе наклепать сколько угодно объектов. Я правильно понимаю что это основная выгода от создания фабричного метода?
Ответы (2 шт):
Я нашел применение в том чтобы не городить много различных классов, вместо этого создать класс с общими характеристиками, их может быть много, но мы используем фабрику для упрощения создания конкретных типов, а где надо используем общие характеристики. Ну и конечно же не создаем объект если не надо, только когда нужен и сколько надо. Перед этим можем указать некоторые харатеристики в классе с фабричным методом. Вообще удобно
В моем понимании весь смысл фабрики сводится к инкапсуляции логики создания объектов. Этому можно найти массу применений, но пожалуй самое важное из них это реализация инверсии зависимостей. Просто сейчас за нас грязную работу проделывают DI-фреймворки.
Попробую привести банальный пример. Представьте, что вам надо написать кучу бизнес-логики, завязанной на отправку SMS, при этом вы скорее всего изучили предметную область и узнали, что смс-шлюзы бывают разные, поэтому сначала завели интерфейс SmsService, а уже потом сделали имплементацию под конкретного вендора - SomeVendorSmsService. Так вот, вы конечно можете ссылаться в бизнес-логике напрямую на наследника, но скорее всего захотите ссылаться только на интерфейс. Зачем? Чтобы в случае чего легко переехать на другого вендора, либо вообще использовать ту или иную реализацию в зависимости от обстоятельств (регион, оператор и т.п) А как вы будете этого достигать если у вас нет DI-фреймворка? Ну наверное вряд ли вы захотите дублировать всю эту логику при каждой необходимости просто отправить SMS. Тут то и нужна фабрика.