Не совсем на билдер похоже. Больше на абстрактную фабрику. Смысл билдера же заменить сеттеры(но иметь возможнсть задать значения самим). Стримы тому пример. Ну и магическая аннотация ломбока Билдер
Задача фабрики как таковой просто создать объект, чья логика создания чуть отличается от тривиального new. Builder же выполняет только действия в том порядке, которые задаёт ему Director, то есть составляет объект по частям по заданному алгоритму. В данном видео как раз таки это чистой воды паттерн Builder.
тоже в нескольких источниках видел билдер в другом варианте например в книге Леонард А. - Java. Решение практических задач Здесь пример больше похож на демонстрацию SOLID
вот чему верить теперь?! Здесь получился какой-то Директор Фабрики. У директора свой план. И он несёт свой план на указанную фабрику. А в стримах роль директора выполняет одна строчка тогда получается.
Не вижу смысла такого билдера. Суть билдера - заменить конструкторы с разными параметрами. Чтобы мы могли построить обьект с разными входными данными. Например построить вебсайт без цены или без Cms. Здесь мы даже данные внутри билдера не можем изменять... Тупо одинаковые обьекти клепаем
Спасибо за урок. Только на мой взгляд не хватает более простого объяснения нафиг это надо в конце видео. По типу "если бы этой штуки не было у нас,мы бы страдали потому-то и потому-то, а когда она у нас есть - то смотрите как жизнь новыми красками заиграла, ибо отныне мы легко и непринужденно можем то-то и то-то. А ещё представьте какой трубопровод тут бы был в большом проекте, если это все смасштабировать! Профит в таком случае ещё больше потому-то и потому-то". Задачи/цели приведены очень сухо в самом начале видео. Например, не очень понял термин "представление" (view? Типо как в MVC?) в данном контексте. А то можно возразить, мол, на кой черт вообще все это городить, если я могу сделать параметризированный конструктор и в цикле в одну строку хоть мильен объектов таких наплодить в контейнер. И мне например не совсем очевидно что можно было бы возразить на такой аргумент. Мне кажется Вы из тех, кто в силу опыта может круто обосновывать такие фичи и жаль, что этого нет. Хронометраж += 2 минуты; импакт *= 3.
Академически правильный билдер, но не понятно где он может понадобится) Хотелось бы увидеть тот самый Lombok'овский билдер, который реально используется и делает жизнь программиста проще и приятнее)
Содержимое класса Director можно было переместить в абстрактный класс WebsiteBuilder без потери какой-либо функциональности. В конструктор WebsiteBuilder добавить вызов абстрактных методов установки имени, cms и цены. Плодить сущности, не являющиеся необходимыми, не лучшая практика.
Спасибо за материалы, что выкладываете. Но в каждом видео я заметил один общий момент. Вы словно бежите на скорость, чтобы выдать все за очень короткий срок. "И что это было...." - каждый раз возникает вопрос. Конечно есть польза того, что такую реализацию можно будет в будущем в чужом коде встретить. Но не хватает глубины. Не показана "боль", которая решается благодаря той или иной теме. Хотя у каждого свой формат подачи, не мне судить. Спасибо, что выкладываете ваш контент.
Спасибо за ваш комментарий и конструктивную критику. Видео записывал довольно давно и тогда не понимал важность объяснения даже малых деталей в том, что касается "базы" - сейчас этот недостаток стараюсь исправлять.
Спасибо за урок! Очень полезно. Отмечу, что также было бы полезно упомянуть про Fluent Builder & Faceted Builder. На мой взгляд они имеют немалое значение. А так на видео базовая реализация паттерна Builder. Кстати, мой любимый паттерн))))
Евгений, здравствуйте! В который раз пересматриваю Ваш курс. На мой взгляд самый качественный из всех, что можно найти на просторах Интернета. И огромное спасибо Вам за это. У меня вот такой вопрос, в абстрактном классе WebSiteBuilder есть поле website у Вас указан с идентификатором доступа packege или по умолчанию. Что очень удобно для того чтобы можно было его с легкостью модифицировать из дочерних классов. Даже если если его изменить на более строгий, и создадим методы который буду предоставлять доступ к этому поля, то это не меняет того, что у нас нарушен один из принципов SOLID, а именно Liskov principle. Чтобы избежать это, может быть, лучше отказаться от абстрактного класса WebSiteBuilder , а реализовать его в качестве интерфейса в котором будут продекларированы только методы. Но уже в конкретной реализации данного интерфейса указывать переменную website c которой и будем дальше работать? Спасибо за ответ.
можно не определять поле website в WebsiteBuilder если наследовать WebsiteBuilder от Website и в дальнейшем просто обращаться сразу к полям Website Или это противоречит каким то принципам ?
если я верно понимаю, то билдер для того, чтобы использовать не обязательно все поля из класса. в вашей интерпретации такой возможности нет. значит это не билдер. но урок интересный
Спасибо за уроки, довольно доступно все разъясняется (особенно после книги "Обьекты, Шаблоны, Методики программирования PHP, в которой если и были примеры то очень запутанные). Сам учу Java после PHP. Скажите, а курс - краткая визуализация книги Банды четырех? Имеет ли смысл читать её после просмотра сего курса?)
Пожалуйста, рад, что видео оказалось полезным :) Да, цель курса - в кратце изложить содержание GoF. Прочитать Банду Четырёх стоит в любом случае, но крайне рекомендуется делать это после 1-2 лет комммерчского опыта, тогда эта книга будет намного понятнее и полезнее. А одной из первых после изучения основ Java я бы рекомендовал - "Рефакторинг", Фаулера.
Не особо понятен смысл применения Директора. В основном классе программы мы передаем в него объект одного из Билдеров, а потом руками в основном же классе запускаем Директором методы, прописанные в Билдере. При этом методы-то по сути - сеттеры с конкретными значениями, без возможности задать их Билдером или Директором. В данном случае есть смысл запускать сеттеры в конструкторе Билдера и отказаться от Директора. Смысл Билдера все равно только в том, чтобы закинуть в сеттеры конкретные значения, так пусть уж делает свою работу без дополнительного подпинывания. На крайний случай тело метода buildWebSIte полностью перенести в конструктор Директора, чтобы от него хоть какой-то толк появился. Иначе как в плохом ООО - Директор вроде есть, но сам не производит никакой полезной работы, просто лишняя коммуникативная прослойка между отделами, полезную работу выполняющими. Либо еще вариант, запускать в основном классе Директор в максимально сжатом виде, типа webSite = Director("web"); и что там будет делать Директор нас уже не касается, если на выходе получим готовый объект вебсайта. А так смысловая нагрузка Директора - просто дать возможность запустить креаторы (по сути сеттеры). Мы и без него можем их запустить.
Отдельный класс директора не является строго обязательным. Вы можете вызывать методы строителя и напрямую из клиентского кода. Тем не менее, директор полезен, если у вас есть несколько способов конструирования продуктов, отличающихся порядком и наличием шагов конструирования. В этом случае вы сможете объединить всю эту логику в одном классе. - refactoring.guru/ru/design-patterns/builder
Большое спасибо за Ваши уроки. Они очень полезные. Многое понятно сразу. Один вопрос. В классе Director в методе Website buildWebsite() указано следующее: Website website = builder.getWebsite(); затем указано return website. Получается своего рода тавтология, так как getWebsite() и так возвращает website. Почему бы вместо вышеуказанного кода не указать просто return builder.getWebsite()? Этот коде тоже будет работать и писать меньше. Может я в чем - то не прав, изучаю Java не так давно, так что извините, если что не так.
Пожалуйста, Валерий :) По поводу метода. В данном случае вы правы, но это учебный материал и во избежание многих вопросов, некоторые моменты далеки от реального кода.
Этот метод называется chaining setters. Что является часто используемым методом. При этом, это не классический шаблон проектирования билдер, который описан в GoF. Лично мое мнение, что здесь стоит помнить о wikipedia.org/wiki/Command%E2%80%93query_separation и нарушении этого подхода при использовании техники, о которой мы говорим. Надеюсь комментарий был полезен. Спасибо.
Здравствуйте!. У вас в классе BuildWebSiteRunner есть публичный доступ к сеттерам объекта webSite. Не является ли это дыркой в безопасности, так как можно после работы директора тупо поменять любое поле при помощи сеттера? Спасибо.
Что-то в этом уроке, показанном примере я не увидел "лайфхаков" Билдера. Все равно ставим статический данные в классе VisitCard. И в итоге суть вся та же ... Спишем на то что это видео устарело
Не совсем на билдер похоже. Больше на абстрактную фабрику. Смысл билдера же заменить сеттеры(но иметь возможнсть задать значения самим). Стримы тому пример. Ну и магическая аннотация ломбока Билдер
тоже не увидел тот билдер который ожидал, в книге effective java указана более понятная реализация билдера
Задача фабрики как таковой просто создать объект, чья логика создания чуть отличается от тривиального new. Builder же выполняет только действия в том порядке, которые задаёт ему Director, то есть составляет объект по частям по заданному алгоритму. В данном видео как раз таки это чистой воды паттерн Builder.
тоже в нескольких источниках видел билдер в другом варианте
например в книге Леонард А. - Java. Решение практических задач
Здесь пример больше похож на демонстрацию SOLID
хотя подобный пример описан в Design Patterns
вот чему верить теперь?!
Здесь получился какой-то Директор Фабрики. У директора свой план. И он несёт свой план на указанную фабрику.
А в стримах роль директора выполняет одна строчка тогда получается.
Не вижу смысла такого билдера. Суть билдера - заменить конструкторы с разными параметрами. Чтобы мы могли построить обьект с разными входными данными. Например построить вебсайт без цены или без Cms.
Здесь мы даже данные внутри билдера не можем изменять... Тупо одинаковые обьекти клепаем
просто счастье какое-то!)
Спасибо за урок. Только на мой взгляд не хватает более простого объяснения нафиг это надо в конце видео. По типу "если бы этой штуки не было у нас,мы бы страдали потому-то и потому-то, а когда она у нас есть - то смотрите как жизнь новыми красками заиграла, ибо отныне мы легко и непринужденно можем то-то и то-то. А ещё представьте какой трубопровод тут бы был в большом проекте, если это все смасштабировать! Профит в таком случае ещё больше потому-то и потому-то".
Задачи/цели приведены очень сухо в самом начале видео. Например, не очень понял термин "представление" (view? Типо как в MVC?) в данном контексте.
А то можно возразить, мол, на кой черт вообще все это городить, если я могу сделать параметризированный конструктор и в цикле в одну строку хоть мильен объектов таких наплодить в контейнер. И мне например не совсем очевидно что можно было бы возразить на такой аргумент.
Мне кажется Вы из тех, кто в силу опыта может круто обосновывать такие фичи и жаль, что этого нет. Хронометраж += 2 минуты; импакт *= 3.
Ну и суперкайф было бы вообще два примера показать: с этой фичей и без нее. Так же, как Вы сделали в ролике про stream api
Спасибо за отзыв, в то время не учёл такой возможности, но вы правы. Это крайне улучшило бы материал.
Академически правильный билдер, но не понятно где он может понадобится) Хотелось бы увидеть тот самый Lombok'овский билдер, который реально используется и делает жизнь программиста проще и приятнее)
Settings-->File and Code Templates-->Includes-->экономия времени и моих нервов)))
Что это означает ?
@@croptv7093 чтобы убрать текст сверху, который автор видео каждый раз стирает
Чёткий видосик👍
Спасибо за комментарий!
Здорово, всё очень понятно
Спасибо!
Очень тяжелый пример для восприятия.
Содержимое класса Director можно было переместить в абстрактный класс WebsiteBuilder без потери какой-либо функциональности. В конструктор WebsiteBuilder добавить вызов абстрактных методов установки имени, cms и цены. Плодить сущности, не являющиеся необходимыми, не лучшая практика.
Спасибо за материалы, что выкладываете.
Но в каждом видео я заметил один общий момент.
Вы словно бежите на скорость, чтобы выдать все за очень короткий срок.
"И что это было...." - каждый раз возникает вопрос.
Конечно есть польза того, что такую реализацию можно будет в будущем в чужом коде встретить.
Но не хватает глубины. Не показана "боль", которая решается благодаря той или иной теме.
Хотя у каждого свой формат подачи, не мне судить.
Спасибо, что выкладываете ваш контент.
Спасибо за ваш комментарий и конструктивную критику.
Видео записывал довольно давно и тогда не понимал важность объяснения даже малых деталей в том, что касается "базы" - сейчас этот недостаток стараюсь исправлять.
Хорошо. Правда скорость пришлось снизить до 0.75 ) слишком уж ты бытсрый и горячие клавиши используешь =)
Понятно, наглядно. Спасибо!
Спасибо за урок! Очень полезно. Отмечу, что также было бы полезно упомянуть про Fluent Builder & Faceted Builder. На мой взгляд они имеют немалое значение. А так на видео базовая реализация паттерна Builder. Кстати, мой любимый паттерн))))
Спасибо!
Спасибо за отзыв!
Евгений, здравствуйте! В который раз пересматриваю Ваш курс. На мой взгляд самый качественный из всех, что можно найти на просторах Интернета. И огромное спасибо Вам за это. У меня вот такой вопрос, в абстрактном классе WebSiteBuilder есть поле website у Вас указан с идентификатором доступа packege или по умолчанию. Что очень удобно для того чтобы можно было его с легкостью модифицировать из дочерних классов. Даже если если его изменить на более строгий, и создадим методы который буду предоставлять доступ к этому поля, то это не меняет того, что у нас нарушен один из принципов SOLID, а именно Liskov principle. Чтобы избежать это, может быть, лучше отказаться от абстрактного класса WebSiteBuilder , а реализовать его в качестве интерфейса в котором будут продекларированы только методы. Но уже в конкретной реализации данного интерфейса указывать переменную website c которой и будем дальше работать? Спасибо за ответ.
Здравствуйте, Александр. Спасибо за отзыв. Да, конечно, можем интерфейс, но, в классике, этот пример использует именно класс, а не интерфейс.
можно не определять поле website в WebsiteBuilder если наследовать WebsiteBuilder от Website и в дальнейшем просто обращаться сразу к полям Website
Или это противоречит каким то принципам ?
если я верно понимаю, то билдер для того, чтобы использовать не обязательно все поля из класса. в вашей интерпретации такой возможности нет. значит это не билдер. но урок интересный
Да, вы правы - в этом примере это не показано.
Спасибо за комментарий и замечание!
WebSite это pojo class ????
Да, мы можем так сказать.
Спасибо за уроки, довольно доступно все разъясняется (особенно после книги "Обьекты, Шаблоны, Методики программирования PHP, в которой если и были примеры то очень запутанные). Сам учу Java после PHP.
Скажите, а курс - краткая визуализация книги Банды четырех? Имеет ли смысл читать её после просмотра сего курса?)
Пожалуйста, рад, что видео оказалось полезным :)
Да, цель курса - в кратце изложить содержание GoF. Прочитать Банду Четырёх стоит в любом случае, но крайне рекомендуется делать это после 1-2 лет комммерчского опыта, тогда эта книга будет намного понятнее и полезнее.
А одной из первых после изучения основ Java я бы рекомендовал - "Рефакторинг", Фаулера.
Не особо понятен смысл применения Директора.
В основном классе программы мы передаем в него объект одного из Билдеров, а потом руками в основном же классе запускаем Директором методы, прописанные в Билдере. При этом методы-то по сути - сеттеры с конкретными значениями, без возможности задать их Билдером или Директором.
В данном случае есть смысл запускать сеттеры в конструкторе Билдера и отказаться от Директора. Смысл Билдера все равно только в том, чтобы закинуть в сеттеры конкретные значения, так пусть уж делает свою работу без дополнительного подпинывания.
На крайний случай тело метода buildWebSIte полностью перенести в конструктор Директора, чтобы от него хоть какой-то толк появился. Иначе как в плохом ООО - Директор вроде есть, но сам не производит никакой полезной работы, просто лишняя коммуникативная прослойка между отделами, полезную работу выполняющими.
Либо еще вариант, запускать в основном классе Директор в максимально сжатом виде, типа webSite = Director("web"); и что там будет делать Директор нас уже не касается, если на выходе получим готовый объект вебсайта.
А так смысловая нагрузка Директора - просто дать возможность запустить креаторы (по сути сеттеры). Мы и без него можем их запустить.
Отдельный класс директора не является строго обязательным. Вы можете вызывать методы строителя и напрямую из клиентского кода. Тем не менее, директор полезен, если у вас есть несколько способов конструирования продуктов, отличающихся порядком и наличием шагов конструирования. В этом случае вы сможете объединить всю эту логику в одном классе. - refactoring.guru/ru/design-patterns/builder
Пожалуй сразу стоит уточнять что это антипаттерн и так делать оч хорошо
Это не паттерн Builder. Это скорее на фабрику похоже.
Большое спасибо за Ваши уроки. Они очень полезные. Многое понятно сразу. Один вопрос. В классе Director в методе
Website buildWebsite() указано следующее: Website website = builder.getWebsite(); затем указано return website. Получается своего рода тавтология, так как getWebsite() и так возвращает website. Почему бы вместо вышеуказанного кода не указать просто return builder.getWebsite()? Этот коде тоже будет работать и писать меньше. Может я в чем - то не прав, изучаю Java не так давно, так что извините, если что не так.
Пожалуйста, Валерий :)
По поводу метода. В данном случае вы правы, но это учебный материал и во избежание многих вопросов, некоторые моменты далеки от реального кода.
Минусы: сеттеры, нарушающие инкапсуляцию. Билдер провоцирует делать анемичную модель. Поощряет также большие классы как таковые
Сеттеры должны возвращать ссылку на экземпляр билдера, а не void
Этот метод называется chaining setters. Что является часто используемым методом.
При этом, это не классический шаблон проектирования билдер, который описан в GoF.
Лично мое мнение, что здесь стоит помнить о wikipedia.org/wiki/Command%E2%80%93query_separation и нарушении этого подхода при использовании техники, о которой мы говорим. Надеюсь комментарий был полезен. Спасибо.
Чего-то ничем не отличается билдер от абстрактной фабрики судя по этому видео
Подскажите, что за плагин, который генерит диаграммы
Стандартный для ultimate версии idea. В community его нет, к сожалению.
Intellij IDEA ultimate, по студенческой подписке первый год бесплатно как и вся остальная продукция JetBrains
Здравствуйте!. У вас в классе BuildWebSiteRunner есть публичный доступ к сеттерам объекта webSite. Не является ли это дыркой в безопасности, так как можно после работы директора тупо поменять любое поле при помощи сеттера? Спасибо.
Что-то в этом уроке, показанном примере я не увидел "лайфхаков" Билдера. Все равно ставим статический данные в классе VisitCard. И в итоге суть вся та же ... Спишем на то что это видео устарело
Было бы классно, если бы были приведены основные отличия от схожих паттернов типа фабрика и фабричный метод, а то так не особо полезно
он не обьесняет, просто решает задачу, ну ооочень плохо, как будто куда то торопитсья ((
Ну таки суть билдера не раскрыл имхо, да и билдер тут спорный