Comments 9
Лучшее сочетание, JS + Marvel !
А где фабричный метод то?.
Суть фабрики или фабричного метода в том, что класс возвращаемого объекта зависит от фактического класса объекта фабрики. А тут обычный кейс внутри. Это уж сервис локатор тогда какой-то и то я не уверен.
Суть фабрики — предоставление интерфейса для создания экземпляров некоего класса с возможностью в момент создания определить, экземпляр какого конкретно класса создавать.
Суть умения рассказать что-то — декомпозировать сложное до простого, упростить до состояния, понятного без дополнительного контекста.
Суть статьи — показать логику реализации, откуда растут ноги этой задачи в игровой, простой форме.
Суть процесса изучения — понять принцип и углубиться в вопрос самостоятельно.
Суть комментариев — найти недосказанное автором)) При желании — можно найти и сервис локатор (только не в свич-кейсе, а в мапе), но в рамках темы статьи — это фигура умолчания.
Суть фабрики, а так же фабричного метода вы понимаете не правильно. Вот для примера: https://refactoring.guru/design-patterns/abstract-factory
Обратите внимание, единственное место где есть if-else - это место где выбирается фабрика. И в этом суть шаблона. Это порождающий шаблон, который "развязывает" источник объектов и множество типов, которые источник выдает. И не просто развязывает, а выносит решение о том, что фабрика будет создавать в design time, у вас же выбор делает "фабрика" и в run time. По сути у вас простой case для создания объектов разных классов. Это называется обычный полиморфизм.
Суть умения рассказывать оценить тут не берусь, ибо говорите одно а пишите другое.
Суть статьи обсуждать безсмысленно, т.к. заявлен фабричный метод, а примеры к паттерну отношения не имеют.
Суть процесса изучения - разбираться как правильно, а не мешать в кучу концепции.
У вас фабрика принимает решение о том, что инстанциировать, а она не должна это делать. Каждая фабрика/фабричный метод делает что-то одно. Выбор происходит по средством подстановки конкретного типа фабрики\класса с фабричным методом.
В данном случае суть комментария в том, что вы не правильно описываете паттерн. И надеюсь, люди примут это во внимание, иначе они будут иметь проблемы с первым же толковом архитектором.
Но оставим это на ответственность читателей :)
Пример по ссылке очень уж далек от практики. Что если мне все фабрики нужны сразу, и выбор нужной при старте не подходит под бизнес логику? Выбор конкретной фабрики будет происходить в run time, а кто все эти фабрики будет порождать? Добро пожаловать switch case по фабрикам?
И да, классический подход фабрики очень уж противоречивый как по мне. У Вас в фабрике есть тре метода порождающие разные объекты(createChair/createSofa/createCoffeeTable), хорошо что метода только 3 а не 103. А как же open closed principle? При добавлении нового предмета лезть в уже написанный класс? А как же single responsibility? Почему методы создающие диван и кресло в одном классе?
Реализация с помощью switch-case хороша для понимания паттерна, но слишком жесткая для практического применения. Если нам потребуется добавить новый тип дрона, или, наоборот, избавиться от уже существующего, — в таком варианте придется править исходный код
Не совсем понял - какая разница, править свитч-кейс или структуру Map?
Никакой. Там вообще ни свича ни мапы быть не должно. Если мы про фабрику или фабричный метод говорим.
Хаммер-дроны, или фабричный метод в действии