Шаблон проектирования ► [ Строитель. Builder ] ► Урок №12
Вставка
- Опубліковано 14 жов 2024
- Строитель (Builder) - это порождающий паттерн проектирования, который позволяет создавать сложные объекты пошагово. Строитель даёт возможность использовать один и тот же код строительства для получения разных представлений объектов.
Так же рассмотрим где шаблон проектирования Билдер (Строитель, builder) используется в Laravel (ларавел).
#шаблоны_проектирования #design_patterns #builder
*
★ Автор: Дмитрий Афанасьев.
★ Телеграм с новостями: t.me/i640kb
★ Канал: clck.ru/JVYct
*
► Выразить благодарность, поддержать донатом развитие канала.
★ www.tinkoff.ru...
★ www.donational...
*
► Еще интересные курсы:
★ Видеокурс по Laravel: clck.ru/JVYa2
★ Видеокурс по Git: clck.ru/JVYYm
★ Объяснение SOLID: clck.ru/JVYXq
★ Шаблоны проектирования: clck.ru/JVYX7
★ Структурные шаблоны проектирования: clck.ru/TVB9Y
★★★ Все курсы → clck.ru/JVYVd
*
► Обязательно к изучению любому разработчику
★ www.ozon.ru/ca...
★ www.chitai-gor...
❤🎉 в 23 году это видео 4х летней давности лучше чем десяток видео в топе текущего года. Объяснение понятно и не как 90% недоразрабов(блохеров) тупо слизано с сайтов о рефакторинге, где даже пример не меняют. 🎉🎉🎉
Спасибо за видео.Коммент в поддержку!
Дмитрий очень толково и понятно обьясняете шаблоны
Спасибо )
Thank you SO MUCH!!!
очень крутой ролик! все понятно!
Great! Класные техники. Подача информации на высоте.
Спасибо большое! Все хорошо и понятно объяснили.
Спасибо большое! В который раз пересматриваю, пригодилось сейчас для тестового задания
Как всегда отличный урок
Отлично рассказываешь, коротко но не сухо. Видео лица снизу тоже помогает за счет невербалики лучше концентрироваться на информации.
Спасибо! Хороший урок!
Спасибо. Материал как всегда на высоте
Хочется видеть видео про тесты. Очень мало качественной информации про тестирование впринципе нахожу. Хотелось бы увидеть уроки от тебя, Дмитрий! =)
Приму на заметку
Абсолютно за, и еще докончить бы Ларавел
Дмитрий с праздником! Успехов в профессиональной деятельности, развития и роста во всех направлениях! Удачи и благополучия.
Благодарю! Симметрично!
Последний пример самый наглядный был, кроме того, знаешь теперь где можно пощупать вживую.
Отличный контент, поэтому просто лайк и комент)
Скажите пожалуйста, какую роль играет отдельный класс билдер? Ведь это все можно светить в самом классе. Для чего нужна ещё одна сущность, абстракция
Отличная подача материала, спасибо! Вопрос не по теме видео. Как вы сделали справа в php storm вывод всех активных файлов? Смотрится очень удобно, но не смог найти где так выставить
Ходил на днях на собеседование в одну небезызвестную компанию, где на вопрос "А почему не спрашиваете про ООП и шаблоны проектирования" ответили: "А вы что, на тим-лида пришли, у нас сеньёры не знают что это" ))
Просто чёт захотелось поделиться. Может мы не тим.лиды, но спасибо что рассказываешь и объясняешь нам всё это.
Интересно какие зп у их синьёров..... И какой код.....
Не знаю, где вы такие собеседования находите. Сейчас даже джун должен это все знать и много больше, даже по мнению мелких контор, занимающихся сайтами для ИПшников.
От конторы к конторе разные определения градаций. Миддл в одной компании при переходе в другую может понять что он всего лишь джун... В сравнении с остальным коллективом... И наоборот.
@@DmitryAfanasyev только вот не попадаются что-то вакансии, где джун может всего этого не знать. Хочется быстрее начать получать опыт, но сегодняшние требования заставляют изучать очень большой массив информации перед тем, как можно будет претендовать на первую работу. Вроде уже и можешь делать много чего, но для устройства на работу вечно чего-то не хватает, например, не знаешь досконально все паттерны, не разобрался до конца в каких-то структурах данных, типа деревьев или не знаешь в тонкостях какой-то инструмент, который использует компания, например, тот же webpack. Ну или SCSS и Pug не знаешь в совершенстве, хотя я и не хочу их особо знать, предпочитаю писать чистый HTML/CSS, мне так удобнее. Но должен знать по мнению работодателя. Значит надо учить. Сейчас джун должен знать и уметь все.
На последнем тестовом задании по PHP/Symfony мне вообще записали в минус, что я контроллеры разношу по отдельным файлам. Хотя по всему интернету куча уроков, где учат делать именно так. И никто не говорит ни слова о том, что это плохая практика и реальным работодателям это не нравится. Да и вообще, делаешь все по ТЗ, а в результате оказывается, что от тебя ждали куда больше. Только узнаешь это постфактум, после отказа.
Супер спасибо :)
Круто. Про билдер я раньше не слышал. И объяснено хорошо. Очень полезный и не сложный паттерн.
Кстати, подобный последовательный вызов методов, это же текучий интерфейс? До ларавел не видел такого. Странно, что о текучем интерфейсе не пишут в учебниках. Выглядит привлекательно.
Дмитрий, большое спасибо за уроки.
Второй подход работы с Builder-ом (225строка) мне напоминает работу с паттерном "Репозитории".
Понятно что у них предназначения разные, но в итоге и там и там происходит "выборки" данных и эти "выборки" оборачиваются в методы, которые реализованы в другом классе. Можно ли в таком контексте их сравнивать для еще лучшего запоминания?
Подскажи: зачем вызывать в конструкторе BlogPostBuilder::create? Понимаю, что в BlogPostBuilder::getBlogPost вызов create нужен, чтобы экземпляр BlogPostBuilder был готов к началу производства следующего BlogPost. Но в конструкторе то зачем? Достаточно же в конструктор поместить создание экзмепляра BlogPost
Потому что логика создания уже есть в функции create. Зачем переписывать то что уже написано ?!
Дмитрий, спасибо за курс! Рассказано понятно и доходчиво. Будет ли еще продолжение курса по паттернам или уже рассмотрены все те, которые более-менее часто могут быть использованы на практике в реальном проекте?
Все отлично объяснили, только текст бы немного по крупнее. А разве не у строителя должны вызываться методы реализации set, get? У вас вызывает объект директора, я видел что это должен делать объект конкретного строителя. Возможно я не верно понял, буду благодарен если дадите обратную связь
Спасибо за уроки, скоро будет продолжение Laravel?
Уже скоро
@@DmitryAfanasyev точно?
Да
@@DmitryAfanasyev (нет)
Будет ли поздравление за прохождение курса?)
Несомненно, но до окончания еще очень далеко
@@DmitryAfanasyev Дмитрий, а почему здесь всегда возвращается $this, а не clone $this как, например, у Zend, в PSR-пакетах, у Симфони или в Laravel. И кстати не совсем понятно зачем нам именно отдельный Строитель, когда у самого класса так же могут быть сеттеры, которые возвращают $this или clone $this или self. Ну я просто тут решил вспомнить теорию по паттернам и кажется перепутал паттерны, можете напомнить к каким паттернам относятся описанные выше примеры?
clone - создает дубликат, а нам нужен текущий.
@@DmitryAfanasyev это да, так например устроен HTTP-пакет в Zend (через clone), но зачем все-таки нужен отдельный Builder, если объект может сам себя достраивать.
@@DmitryAfanasyev ну так какой смысл использовать Строитель, если можно в самом классе создать геттеры и сеттеры, и даже сделать return $this или return clone $this во всех этих методах?
А зачем куча свойств в конструкторе? Почему нельзя сеттеры в сам класс добавить? Вижу смысл только если работаем с готовым классом который хотим более понятным сделать
скажи, а зачем из сеттера что то возвращать?
Автор возвращает не "что-то", а именно текущий объект и это очень важно. Это удобно для того, чтобы писать всё в одной строке.
Например, если не возвращать $this, то код выглядел бы следующим образом:
$builder = new Builder();
$builder->setName('Pavel');
$builder->setPhone(000000);
Всё придётся писать с новых строк так, как результат выполнения сеттеров возвращает null. Поэтому вы можете вернуть текущий объект - $this и писать всё это в одну строчку.
$builder = new Builder();
$builder->setName('Pavel')->setPhone(000000);
@@TimmertPlay спасибо
Если не ошибаюсь - возврат в сеттере (и не только в сеттере) текущий объект с целью создать возможность реализации цепочки вызовов - тоже шаблон проектирования.
obj.setX(x1).setY(y1).getResult();
@@DmitryAfanasyev спасибо 🙏
Отличные материалы, Дмитрий! Благодарен за качественную информацию!
Однако, у меня возникает вопрос относительно того, что Вы часто используете сеттеры. При этом, я видел выступление Егора Бугаенко, который говорит о том, что геттеры и сеттеры не соответствуют идеологии ООП. И о том, что если от них избавиться, то иначе сформируется мышление программиста, более "правильно" и ООПешно. Что думаете по этому поводу? Очень хочу узнать Ваше профессиональное мнение, чтобы прояснить ситуацию для себя.
Вот ссылка на выступление Егора ua-cam.com/video/lfdAwl3-X_c/v-deo.html
Использую геттеры и сеттеры если надо "защитить" переменную от прямого обращения. Если такой надобности нет - то не использую. Что касается "ИДИОЛОГИИ ООП" - то в малину любую идеологию, в малину любые рамки. Надо писать код так чтобы было понятно и можно было без вскрытия вен рефакторить. Если какой-либо приём выходит за рамки "идеологии ооп", но при этом использование этого приема будет и проще и понятнее - я буду его использовать.
Бугаенко радикал, его надо с коэффициентом воспринимать
Ну пример, так себе, посты можно генерировать фикстурами
Какой пример лучше?
@@DmitryAfanasyev Было бы лучше, если увидеть прям на примере кода, как строитель делал бы более приближенные к реальности задачи. Например, были бы к новостям еще категории связанные, даже тогда будет поинтереснее, билдер который билдит еще и зависимости. Как он в этой ситуации будет делать, обратиться к другому билдеру или сам же эти будет заниматься
Питонисты конечно геи, но объяснил паттерн хорошо, особенно часть с Director
Под питонистами вы вероятно имели в виду PHP-шников? :D Канал-то "PHP-ориентированный" ))))
@@DmitryAfanasyev Ой, реально php.
Не, php разрабов я бы не принижал.
Думаю, вы как легаси код - избавиться бы и заменить, но его слишком много и можно накосячить, поэтому пусть будет
Я могу ошибаться, тк лично не общался php разрабочиками и не работал с кодом
Я dotnetчик (не путать с минетчиком)
Менеджер это конечно хорошо, но к самому паттерну Builder он не относиться
в первоисточник GoF он описан как часть паттерна
Сколько же тут воды боже мой
Го на википедию, там сухо аки в сахаре