Шаблоны Java. Builder (Строитель)

[@nikita3967]

Не совсем на билдер похоже. Больше на абстрактную фабрику. Смысл билдера же заменить сеттеры(но иметь возможнсть задать значения самим). Стримы тому пример. Ну и магическая аннотация ломбока Билдер

[@ascar66]

тоже не увидел тот билдер который ожидал, в книге effective java указана более понятная реализация билдера

[@malloc2497]

Задача фабрики как таковой просто создать объект, чья логика создания чуть отличается от тривиального new. Builder же выполняет только действия в том порядке, которые задаёт ему Director, то есть составляет объект по частям по заданному алгоритму. В данном видео как раз таки это чистой воды паттерн Builder.

[@Das.Kleine.Krokodil]

тоже в нескольких источниках видел билдер в другом варианте например в книге Леонард А. - Java. Решение практических задач Здесь пример больше похож на демонстрацию SOLID

[@Das.Kleine.Krokodil]

хотя подобный пример описан в Design Patterns

[@VirKato]

вот чему верить теперь?! Здесь получился какой-то Директор Фабрики. У директора свой план. И он несёт свой план на указанную фабрику. А в стримах роль директора выполняет одна строчка тогда получается.

[@ГлебВалерьевич-у6ы]

просто счастье какое-то!)

[@МиколаПаславський-н9й]

Не вижу смысла такого билдера. Суть билдера - заменить конструкторы с разными параметрами. Чтобы мы могли построить обьект с разными входными данными. Например построить вебсайт без цены или без Cms. Здесь мы даже данные внутри билдера не можем изменять... Тупо одинаковые обьекти клепаем

[@johnconstantine6331]

Спасибо за урок. Только на мой взгляд не хватает более простого объяснения нафиг это надо в конце видео. По типу "если бы этой штуки не было у нас,мы бы страдали потому-то и потому-то, а когда она у нас есть - то смотрите как жизнь новыми красками заиграла, ибо отныне мы легко и непринужденно можем то-то и то-то. А ещё представьте какой трубопровод тут бы был в большом проекте, если это все смасштабировать! Профит в таком случае ещё больше потому-то и потому-то". Задачи/цели приведены очень сухо в самом начале видео. Например, не очень понял термин "представление" (view? Типо как в MVC?) в данном контексте. А то можно возразить, мол, на кой черт вообще все это городить, если я могу сделать параметризированный конструктор и в цикле в одну строку хоть мильен объектов таких наплодить в контейнер. И мне например не совсем очевидно что можно было бы возразить на такой аргумент. Мне кажется Вы из тех, кто в силу опыта может круто обосновывать такие фичи и жаль, что этого нет. Хронометраж += 2 минуты; импакт *= 3.

[@johnconstantine6331]

Ну и суперкайф было бы вообще два примера показать: с этой фичей и без нее. Так же, как Вы сделали в ролике про stream api

[@EugeneSuleimanov]

Спасибо за отзыв, в то время не учёл такой возможности, но вы правы. Это крайне улучшило бы материал.

[@streiker]

Settings-->File and Code Templates-->Includes-->экономия времени и моих нервов)))

[@croptv7093]

Что это означает ?

[@IbnSabilAbuAbdullah]

@@croptv7093 чтобы убрать текст сверху, который автор видео каждый раз стирает

[@dreamer_vi905]

Академически правильный билдер, но не понятно где он может понадобится) Хотелось бы увидеть тот самый Lombok'овский билдер, который реально используется и делает жизнь программиста проще и приятнее)

[@Youtooobo]

Очень тяжелый пример для восприятия.

[@СергейКаштанов-у2э]

Чёткий видосик👍

[@EugeneSuleimanov]

Спасибо за комментарий!

[@Andrzej3935]

Здорово, всё очень понятно

[@EugeneSuleimanov]

Спасибо!

[@ЕвгенийБелых-к9э]

Спасибо за материалы, что выкладываете. Но в каждом видео я заметил один общий момент. Вы словно бежите на скорость, чтобы выдать все за очень короткий срок. "И что это было...." - каждый раз возникает вопрос. Конечно есть польза того, что такую реализацию можно будет в будущем в чужом коде встретить. Но не хватает глубины. Не показана "боль", которая решается благодаря той или иной теме. Хотя у каждого свой формат подачи, не мне судить. Спасибо, что выкладываете ваш контент.

[@EugeneSuleimanov]

Спасибо за ваш комментарий и конструктивную критику. Видео записывал довольно давно и тогда не понимал важность объяснения даже малых деталей в том, что касается "базы" - сейчас этот недостаток стараюсь исправлять.

[@ttampuom]

Содержимое класса Director можно было переместить в абстрактный класс WebsiteBuilder без потери какой-либо функциональности. В конструктор WebsiteBuilder добавить вызов абстрактных методов установки имени, cms и цены. Плодить сущности, не являющиеся необходимыми, не лучшая практика.

[@ВладиславМелехин-е5р]

Понятно, наглядно. Спасибо!

[@warflow]

можно не определять поле website в WebsiteBuilder если наследовать WebsiteBuilder от Website и в дальнейшем просто обращаться сразу к полям Website Или это противоречит каким то принципам ?

[@AlexRom1986]

Евгений, здравствуйте! В который раз пересматриваю Ваш курс. На мой взгляд самый качественный из всех, что можно найти на просторах Интернета. И огромное спасибо Вам за это. У меня вот такой вопрос, в абстрактном классе WebSiteBuilder есть поле website у Вас указан с идентификатором доступа packege или по умолчанию. Что очень удобно для того чтобы можно было его с легкостью модифицировать из дочерних классов. Даже если если его изменить на более строгий, и создадим методы который буду предоставлять доступ к этому поля, то это не меняет того, что у нас нарушен один из принципов SOLID, а именно Liskov principle. Чтобы избежать это, может быть, лучше отказаться от абстрактного класса WebSiteBuilder , а реализовать его в качестве интерфейса в котором будут продекларированы только методы. Но уже в конкретной реализации данного интерфейса указывать переменную website c которой и будем дальше работать? Спасибо за ответ.

[@EugeneSuleimanov]

Здравствуйте, Александр. Спасибо за отзыв. Да, конечно, можем интерфейс, но, в классике, этот пример использует именно класс, а не интерфейс.

[@КириллСазонов-м4ц]

Хорошо. Правда скорость пришлось снизить до 0.75 ) слишком уж ты бытсрый и горячие клавиши используешь =)

[@withotsoul7252]

Спасибо!

[@EugeneSuleimanov]

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

[@anatoliikozyura643]

Спасибо за уроки, довольно доступно все разъясняется (особенно после книги "Обьекты, Шаблоны, Методики программирования PHP, в которой если и были примеры то очень запутанные). Сам учу Java после PHP. Скажите, а курс - краткая визуализация книги Банды четырех? Имеет ли смысл читать её после просмотра сего курса?)

[@EugeneSuleimanov]

Пожалуйста, рад, что видео оказалось полезным :) Да, цель курса - в кратце изложить содержание GoF. Прочитать Банду Четырёх стоит в любом случае, но крайне рекомендуется делать это после 1-2 лет комммерчского опыта, тогда эта книга будет намного понятнее и полезнее. А одной из первых после изучения основ Java я бы рекомендовал - "Рефакторинг", Фаулера.

[@azerphoenix]

Спасибо за урок! Очень полезно. Отмечу, что также было бы полезно упомянуть про Fluent Builder & Faceted Builder. На мой взгляд они имеют немалое значение. А так на видео базовая реализация паттерна Builder. Кстати, мой любимый паттерн))))

[@pie4928]

WebSite это pojo class ????

[@EugeneSuleimanov]

Да, мы можем так сказать.

[@anikroan4357]

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

[@EugeneSuleimanov]

Да, вы правы - в этом примере это не показано. Спасибо за комментарий и замечание!

[@ValeriyTokarev]

Большое спасибо за Ваши уроки. Они очень полезные. Многое понятно сразу. Один вопрос. В классе Director в методе Website buildWebsite() указано следующее: Website website = builder.getWebsite(); затем указано return website. Получается своего рода тавтология, так как getWebsite() и так возвращает website. Почему бы вместо вышеуказанного кода не указать просто return builder.getWebsite()? Этот коде тоже будет работать и писать меньше. Может я в чем - то не прав, изучаю Java не так давно, так что извините, если что не так.

[@EugeneSuleimanov]

Пожалуйста, Валерий :) По поводу метода. В данном случае вы правы, но это учебный материал и во избежание многих вопросов, некоторые моменты далеки от реального кода.

[@АлександрМан-в6ъ]

Подскажите, что за плагин, который генерит диаграммы

[@EugeneSuleimanov]

Стандартный для ultimate версии idea. В community его нет, к сожалению.

[@АдлетАдилханов]

Intellij IDEA ultimate, по студенческой подписке первый год бесплатно как и вся остальная продукция JetBrains

[@ivanaldabaev1187]

Здравствуйте!. У вас в классе BuildWebSiteRunner есть публичный доступ к сеттерам объекта webSite. Не является ли это дыркой в безопасности, так как можно после работы директора тупо поменять любое поле при помощи сеттера? Спасибо.

[@vadimmorozov30]

Пожалуй сразу стоит уточнять что это антипаттерн и так делать оч хорошо

[@StrDimka]

Чего-то ничем не отличается билдер от абстрактной фабрики судя по этому видео

[@nmodonov]

Не особо понятен смысл применения Директора. В основном классе программы мы передаем в него объект одного из Билдеров, а потом руками в основном же классе запускаем Директором методы, прописанные в Билдере. При этом методы-то по сути - сеттеры с конкретными значениями, без возможности задать их Билдером или Директором. В данном случае есть смысл запускать сеттеры в конструкторе Билдера и отказаться от Директора. Смысл Билдера все равно только в том, чтобы закинуть в сеттеры конкретные значения, так пусть уж делает свою работу без дополнительного подпинывания. На крайний случай тело метода buildWebSIte полностью перенести в конструктор Директора, чтобы от него хоть какой-то толк появился. Иначе как в плохом ООО - Директор вроде есть, но сам не производит никакой полезной работы, просто лишняя коммуникативная прослойка между отделами, полезную работу выполняющими. Либо еще вариант, запускать в основном классе Директор в максимально сжатом виде, типа webSite = Director("web"); и что там будет делать Директор нас уже не касается, если на выходе получим готовый объект вебсайта. А так смысловая нагрузка Директора - просто дать возможность запустить креаторы (по сути сеттеры). Мы и без него можем их запустить.

[@maximkhvatov7911]

Отдельный класс директора не является строго обязательным. Вы можете вызывать методы строителя и напрямую из клиентского кода. Тем не менее, директор полезен, если у вас есть несколько способов конструирования продуктов, отличающихся порядком и наличием шагов конструирования. В этом случае вы сможете объединить всю эту логику в одном классе. - refactoring.guru/ru/design-patterns/builder

[@57m57]

Это не паттерн Builder. Это скорее на фабрику похоже.

[@ВиталийМорозов-в5ъ]

Сеттеры должны возвращать ссылку на экземпляр билдера, а не void

[@EugeneSuleimanov]

Этот метод называется chaining setters. Что является часто используемым методом. При этом, это не классический шаблон проектирования билдер, который описан в GoF. Лично мое мнение, что здесь стоит помнить о wikipedia.org/wiki/Command%E2%80%93query_separation и нарушении этого подхода при использовании техники, о которой мы говорим. Надеюсь комментарий был полезен. Спасибо.

[@ahmedrapira7610]

Минусы: сеттеры, нарушающие инкапсуляцию. Билдер провоцирует делать анемичную модель. Поощряет также большие классы как таковые

[@aspa-n-fyt7785]

Что-то в этом уроке, показанном примере я не увидел "лайфхаков" Билдера. Все равно ставим статический данные в классе VisitCard. И в итоге суть вся та же ... Спишем на то что это видео устарело

[@FishL0L]

Было бы классно, если бы были приведены основные отличия от схожих паттернов типа фабрика и фабричный метод, а то так не особо полезно

[@Григорий-ь5ь7о]

он не обьесняет, просто решает задачу, ну ооочень плохо, как будто куда то торопитсья ((

[@ololo2755]

Ну таки суть билдера не раскрыл имхо, да и билдер тут спорный