Шаблоны Java. FactoryMethod (Фабричный метод) 

именно! Если вы поняли зачем это, то не могли бы вы объяснить?

@@_camper_5769 не зачем, прост. Притянуто за уши для демонстрации примера создания фабрики. В этом и печаль большинства блогеров-публицистов.

Рад тому, что увидел этот коммент, т.к. тоже не понимал, зачем этот уровень, если можно по слову сразу возвращаться нужного RandomLanguageDeveloper. Думал, что я не понимаю чего-то, но оказалось, что правильно подумал.

потому что switch/case нужно стараться избегать, вследствие одного из принципов solid, а точнее его второго принципа. при создании объекта, придется еще лезть под это switch и там добавлять условие, что не есть хорошо, на самом то деле.

Я согласен, что следует всегда минимизировать условную логику трансформируя такой код в полиморфизм иерархии наследования. Но в данном случае разве мы избавились от условной логики? Мы просто её переместили, а значит ровным счётом ничего не достигли.

да, куда лучше чем в обьясняли

Правильно, даешь супер-класс где все до кучи и авер 500 строк кода, вот так сразу все понятно будет

Спасибо за отзыв!

Спасибо за отзыв! Рад , что материал помог разобраться.

Спасибо за отзыв!

Спасибо за отзыв :)

Спасибо за отзыв!

как ваши успехи в разработке спустя 6 лет?

@@user-er5uz4os1t спился

Спасибо за отзыв!

Пожалуйста, Дарья.

цель фабрик - создание ОБЪЕКТОВ и инкапсуляция создания объекта вне клиентского кода, тем самым мы освобождаем клиента от больших изменений кода (как показано на примере метода main), а все изменения инкапсулируем в объекте "фабрика", тем самым не нарушаем принцип открытости к расширению программы и закрытости к ее изменению уже существующего кода. Это фишка, которая предоставляет нам ООП. Используя Фабричный метод создаётся ОБЪЕКТ классами (JavaDeveloperFactory и PHPdeveloper factory), реализующими абстракцию (DeveloperFactory) для создания объекта интерфейса (Developer). Т.е. используется наследование для реализации этого метода. Абстрактная фабрика создаёт СЕМЕЙСТВО ОБЪЕКТОВ. Абстрактная фабрика используется с помощью композиции, т.е. создав в клиенте экземпляр абстрактной фабрики, ты задаешь создание всех объектов сразу, которые представляют собой одно семейство объектов (ингредиенты к блюду, виды цветов в одном букете, и тд). И используешь объекты этого семейства. Читай HeadfirstJava паттерны. Фабрика

Абстрактная фабрика, состоит из фабричных методов

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

@@EugeneSuleimanov желательно было это и упомянуть в видео)

День добрый, Дмитрий. Спасибо за отзыв. Это стандартный плагин, который входит с Ultimate Edition. В Community его, к сожалению, нет.

@@EugeneSuleimanov Евгений, а есть ли достойная замена для Community Edition? По вашему мнению?

@@Dmitry2385 ultimate edition :) По моему мнению - Jet Brains делает лучшие IDE. А для Java - лучше IDEA точно нет.

@@EugeneSuleimanov Евгений, я имел ввиду uml plugin для idea Community edition.

в каких источниках описан шаблон с названием Factory?

Пожалуйста, Андрей. Спасибо за отзыв )

И это прискорбно

Тоже в голову мысль пришла ограничить варианты через перечисления.

@@user-sj9kh4pf7n да, это норм практика, так можно не переживать, что кто-то, передаст что-то не то )))

Все советуют использовать только enum , в строке легко ошибиться , нежели в перечисление .

Можно ожидать Developer как параметр и передавать нужный класс и делать instanceof для нужной фабрики

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

Полиморфизм даёт нам позможность переопределять поведение класса, а фабрика отвечает за создание объектов. А код в клиентском классе является лишь примером использования.

То, что код - это лишь пример, я понимаю. Не могу сообразить, чем создание объектов в фабрике предпочтительнее непосредственного создания объектов. И так, и так, для добавления новых классов или изменения типов объектов надо править код, вся разница, что без паттерна мы правим код в клиенте, а с паттерном - в классе фабрики. Что мы этим выигрываем? Или есть еще что-то, что я не понял?

Tariel Regev Вероятнее всего, вы не сталкивались с по-настоящему сложными системами, в которых мы изначально не имеем всех данных для создания объекта, а получаем их из разных источников. Ведь, если нам необходима ссылка на какой-то объект SomeObject, то, намного разумнее поместить эту ссылку в фабрику а не в клиентский код.

вот именно. а вообще взялся учить по этому сайту. вроде очень даже хороший refactoring.guru/ru/design-patterns/factory-method

Попробую пояснить полезность фабричного метода. Если в вашем коде будет много мест с "Developer developer = new JavaDeveloper". Представим 100 таких инициализаций класса. То когда вы захотите заменить JavaDeveloper на CppDeveloper, не смотря на то что вы использовали интерфейс, вам все равно придется сделать 100 изменений в коде. А фабричный метод инкапсулирует в себе инициализацию объекта определенного класса.(new JavaDeveloper) . Таким образом в данном кейсе вы заменяете "new JavaDeveloper" на "new CppDeveloper" только в одном месте внутри Фабрики, а в тех старых местах инициализации будет стандартный код "Developer developer = developerFabric.createDeveloper() "

@@EllaLavrik т.е. мы просто создаем "промежуточную переменную" , через которую идет создание новых объектов и когда нам надо поменять этот класс на другой мы типа меняем ссылку в этой переменной а все наши созданные объекты ее автоматом подхватывают? Правильно я понял? У меня один вопрос, а что так часто приходится изменять классы в реальных проектах? Вот только если нам надо просто добавить новый класс фабрика (из вышеприведенного примера) нам ни как в этом не поможет, т.к. кол-во приседаний от этого не уменьшается. Или я не прав?

@@EllaLavrik А каким образом с точки зрения количества кода создание 100 java девелоперов в фабрике проще?

@@lighto263 оно не проще. Суть именно в подходе к инициализации. Допустим(!!!), что программисту на ассемблере надо знать только ассемблер и архитектуру процессоров. То есть его инициализация состоит только в подготовке знаний самого ассемблера и АП. Всего две строки. А программисту на котлине надо знать Java Core, десяток библиотек и фреймворков, кучи паттернов, этой же кучи паттернов, но уже для Java и Kotlin, и собственно котлин. Например, инициализация такого программиста состоит из 20 строк. Итого, у нас получилась портянка IF'ов из 30 строк, и это только на два языка. Добавляем еще C++, C#, JS, TS - и, вуаля, у нас уже только стратегия выбора и инициализации программиста разрослась в 1000 строк трудноусвояемых условий. Читать такой код уже сложно. А в ходе развития задачи мы постоянно добавляем новые языки в эту, с позволения сказать, фабрику программистов. Паттерн "фабрика" же позволяет реализации создани и инициализации первичных параметров вынести в отдельный класс/объект. Каждый такой объект сам определяет, как ему создавать экземпляр - у кого-то пара строк, а у кого-то сотня, плюс хождения во внешние системы и тяжелая математика. А вот стратегия выбора способа создания конкретного программиста становится очень компактным и линейным кодом, который влазит уже в экран. Да, дальше можно стратегию сделать еще более "правильной", не требуя создавать портянку IF'ов, но это уже совсем другая история. Резюмируя, паттерн Factory нужен в первую очередь для улучшения читаемости, и снижения complexity кода.

Нет, это плохая идея. Для примитивного класса Developer может и годится (и то, так себе идея), для чего-то серьёзного - нет.

Дякую за відгук

Вероятнее всего вы не смотрели введение и не обратили внимание на цель этого курса. Но, в чем-то вы, возможно, правы.

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

ясно, спасибо

что и как и так понятно. Ответь на вопрос ЗАЧЕМ?

Актуальный вопрос спустя 3 года, таки ЗАЧЕМ?

@@hexruin4569 на самом деле в каждой фабрике для наглядности тоже должны быть ветвления. Например тестировщика, разработчика, техлида. Реализовать это вне фабрики будет проблематично, поэтому удобно будет вынести это так как указал автор. С одним лишь методом в фабрике это действительно бессмысленно. В данном случае достаточно интерфейса девелопера

Например создание девелопера может быть не таким простым. А девелопер фактори инкапсулирует конкретную реализацию девелопера

@@JohnWickMovie а каким это не простым ? есть ли примеры ? если весь процесс создания инкапуслирован внутри конструктора класса "девелопер", и фабрика при этом ничего не вызывает кроме как конструктор этого класса. upd: это может быть вызов разных конструкторов, в зависимости от ситуации? И мы как бы скрываем из основного метода MAIN большую часть портянки блоков IF / SWITCH в этих самых фабриках, и таким образом получаем более красивое архитектурно решение?

@@kolob204 Здесь просто демонстрируется пример абстракции. В жизни случают сложные ситуации, например тебе нужно отслеживать создание объектов или аллоцировать его в собственном участке памяти, фабрики это позволят легко делать. Да и весь COM от Microsoft построен подобным образом, взгляни на какой нибудь DirectX на досуге, в качестве примера фабрики

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

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

Спасибо за отзыв!

Зачем? Как вы создадите экземпляр класса из ничего? цель фабрик в отделении создании объектов от неизменяемой части кода, а не в отделении клиентского кода от созданий объектов в принципе!

все правильно вы говорите, странно что в клиенте сделано придется такую логику теперь писать в каждом клиенте

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

Можно, но это будет не самым простым к пониманию решением. Можно создать ассоциативный массив String->Factory, и при инициализации его заполнять всеми возможными билдерами. Доступ к нужному в таком случае произойдёт просто по индексу. Да и заполнение такой коллекции можно сделать через рефлексию или Dependency Injection, но это уже совсем энтерпрайзно. Но это всё уже не к шаблону Factory, а скорее к Strategy.

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

Я то же не особо понял плюсов, а что мешает так же создать метод который вернет нужный класс, если мы на каждый класс делаем свою фабрику?

+++ вообще непонятно вместо пары строк такая лапша

@@vsezanyato ну автор, на мой взгяд, взял не самый лучший пример. На самом деле может быть и одна фабрика (например, в конкретном примере). Но в сложных проектах дела обстоят по другому и создание фабрики фабрик оправдано. Например, есть Enum с условным DeveloperTier (Junior, Middle, Senior), и уже исходя из него и будет создаваться Developer. Factory factory = createDeveloperFactory("java"); Developer developer = factory.createDeveloper(DeveloperTier.SENIOR) developer.writeCode();

@@TheSporpion, ничего не мешает, автор создал очень плохую реализацию, с совершенно лишним слоем фабрик, еще и в клиентский класс запихнул функцию создания фабрик, которую придется менять, хотя изначально именно к изменениям в клиентском классе была претензия.

Безусловно

Доброе утро, Михаил. Это стандартный плагин, который входит только в ULTIMATE версию IDEA. По-другому получить его, вряд ли, получится.

Потому что объекты могут быть крайне сложными и выносить инициализация в клиентский код не практично

Добрый день, Михали. Да, конечно, можно.

Я так и делаю, по сути в примере это обычный флаг, в таком случае использую enam-ы.

Добрый вечер, Евгений. Это стандартный плагин в Intellij IDEA Ultimate edition. Т.е. в community такого плагина нет

@@EugeneSuleimanov спасибо

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

@@EugeneSuleimanov принцип как MVC

Спасибо за комментарий! Старался делать в точности по материалам GoF, если подскажите, где было отклонение от их примеров - буду признателен.

@@EugeneSuleimanov там все было Ок, на мой взгляд, до появления статического метода получения разработчика по специальности. Этот метод нарушает принцип open/close.

Автор, вот лучше ответил бы на вопрос: почему я не могу возвращать из метода с if'ми сразу экземпляр класса тем более что метод называется createDeveloper а не createFactory? Зачем мне прослойка из структуры фабрик между клиентом и реализациями интерфейса? Вот на такие вопросы надо давать ответы в видео а не просто кратко пересказывать содержимое книги.

Афобий II просмотр введения в цикл даст ответы на все вопросы

Более обобщенно - фабрика может скрыть любую логику по созданию объекта - например создание объекта, который требует параметры в конструктор, кеширование, выбор между несколькими реализациями, скачивание данных (даже класса возвращаемого объекта) из интернета

Она до сих пор приходит ко мне во снах :)

Не лучше, switch жёстче, чем if else, т.к. зависит от конкретного сравниваемой переменной и ее типа

В switch ignorecase не получится

Она не выдержала :)

Это реализация шаблона по GoF. Если вы не согласны с их подходом к проектированию... Без комментариев.

Даже если ты не прав, с таким ответом, свою неправоту уже не признаешь. Не ссылок, ни примеров. Разве в книге нет примера фабричного метода с параметром?

Странный комментарий. Раз 10 перечитал - так и не понял о чём он. Понял только вопрос. Отвечаю: В книге есть пример, но несколько более сложный и его трудно использовать без контекста всей книги.

Я ничего утверждаю, но возможно своим упрощением вы разрушали основную идею паттерна. :))

Какое упрощение? Паттерн сделан стандартно - а клиентский класс всего лишь демонстрирует его работу.