Я не создавал интерфейс PersonBuilder, а менял логику PersonBuilderIMpl только в возвратах метода (собственный объект, т.е. PersonBuilderIMpl). public PersonBuilderIMpl setAge(int age) { person.age=age; return this; } т.е. по сути объекта PersonBuilderIMpl с полем peson, который будет каждый раз возвращать сам себя, пока не будет build() метода достаточно... Я не прав?
есть вопрос) если я удалю интерфейс и оставлю вспомогательный класс со всеми его методами, изменив только то что методы возвращают( то есть уже сам вспомогательный класс а не интерфейс) все будет работать точно так же. и я все так же смогу использовать не все поля. и создать сколько угодно разный Person. зачем тогда в данном примере интерфейс?
А почему просто в Персоне написать сеттеры и заполнять только нужные поля?? в чем такой подход проигрывает показанному в видео? (А то про шаблон рассказали,а почему его выгоднее использовать не особо понятно)))
Если использовать сеттеры что бы создать объект с 10 полями нужно 11 строчек кода, используюя билдер, можно создать все в одну строчку - new PersonBuilderImpl().setFirst().setSecond.setThird()....build()
@@husivm А как часто этот паттерн применяется на практике? Ну актуален он я так понимаю будет в POJO. Так что тогда лучше, использовать паттерн Builder + структуру POJO или всё таки конфигурацию IoC вместе с их адаптивными моделями, которые не требуют создания экземпляров по всему проекту? В плане простоты. Если мы уж берём этот патерн для простоты и читабельности.
Судя по другому ролику, смысл в том, что основной класс является immutable, т.е. неизменяемым - нельзя через сеттеры задавать новые значения полям - только через конструкторы, которых будет слишком много А на примере автора можно просто создать сеттеры и не страдать чушью, типа "теперь мы можем заполнить свойства объекта в одну строчку"
Тут билдер больше нужен, если у вас множество полей, но вы не все их хотите заполнять или разное их сочетание. И в целом можно обойтись конструктором, но вы явно будете прописывать null. А с помощью билдера вы собираете нужные вам поля и создаете класс. Но соглашусь, что то, как это подано у автора, можно спокойно воспользоваться сеттерами.
Всё верно. Смысл в том, что объект иммутабельный, а у автора, кроме того, что можно воспользоваться просто сетерами, так и нарушена инкапсуляция так как поля не закрытые. Понятно, что это сделано для примера, но всё равно, так делать нельзя даже в примерах. Это базовая, фундаментальная вещь, которая должна быть всегда.
Ну во первых я пишу все в одном файле для наглядности и не разбиваю на разные файлы и пакеты и не ставлю private для экономии времени, а во вторых даже если вы будете сетить каждое поле в отдельной строчке то что бы создать объект с 10 полями нужно 11 строчек кода, а используюя билдер можно создать все в одну строчку - new PersonBuilderImpl().setFirst().setSecond.setThird()....build()
Стоит ли использовать builder в случае если нужно проверять параметры при создании экземпляра на согласованность? Например есть класс "Регион". У него есть столица/региональный центр и просто города. По очевидным причинам, региональный центр должен лежать во множестве городов, площадь региона не должна быть меньше суммы площадей населённых пунктов и.т.д. Хотелось бы отлавливать неправильно переданные комбинации параметров, но при этом не делать этого в основном конструкторе. Если возможно, то как это можно сделать?
Можно сделать конструктор PersonBuilderImpl с нужными параметрами. Таким образом пользователь будет обязан ввести значение поля в конструкторе, иначе он не сможет создать Builder
А вобще у меня сейчас на работе линукс, дома винда, а видео записываю на маке потому что его можно взять в коворкинг, работаю на всем и разницы не особо замечаю
А как засетать значения юзеру(в методе у билдера), если нет сетеров у него, я имею ввиду, что поля юзера будут приватными в реальной программе и дав ему сетеры, то это лишает смысла этого паттерна, как быть тогда ?
Нет, сеттеры не лишают смысла, суть паттерна в том что если у тебя много поелей, и тебе надо их сетить через конструктор, при этом ты не знаешь какие поля будут сетиться, ты создашь миллион констукторов, что бы этого не делать, можно использовать паттерн билдер, при этом можно спокойно иметь сеттеры и геттеры и любой другой код который использует эти поля
@@husivm понял, спасибо, например в реализации с nested классом(либо у Вас/Джошуа Блох(Effective java), там нет сеттеров и поля вообще финальные, и насколько я понял объект получается immutable, мы один раз сбилдали и всё, либо можно не возвращать новый объект(внешнего класса), а сделать композицией и возращать новый, только если этот налл, это к примеру если нужно что-то перезасетать в объект после создания
чтобы засетать все параметры в одну строку. Если метод будет void, то мы не получим объект, к которому после точки можно дописывать следующие сеттеры по цепочке.
Чтобы объект возвращал сам себя и можно было цепочкой сетапить данные по типу obj.name('Max').surname('Brown').build(); и только build() возвращает сам объект
в книгах встречал, что имена сеттеров билдера делают без слова set
т.е. в вызов такой получается ...name("mike").age(20)...
ага в библиотеке Lombok именно так.
Я не создавал интерфейс PersonBuilder, а менял логику PersonBuilderIMpl только в возвратах метода (собственный объект, т.е. PersonBuilderIMpl).
public PersonBuilderIMpl setAge(int age) {
person.age=age;
return this;
}
т.е. по сути объекта PersonBuilderIMpl с полем peson, который будет каждый раз возвращать сам себя, пока не будет build() метода достаточно... Я не прав?
есть вопрос) если я удалю интерфейс и оставлю вспомогательный класс со всеми его методами, изменив только то что методы возвращают( то есть уже сам вспомогательный класс а не интерфейс) все будет работать точно так же. и я все так же смогу использовать не все поля. и создать сколько угодно разный Person. зачем тогда в данном примере интерфейс?
Обязателен ли интерфейс? Или можно просто писать класс PersonBuilder?
Я тоже не понял зачем интерфейс
А почему просто в Персоне написать сеттеры и заполнять только нужные поля?? в чем такой подход проигрывает показанному в видео? (А то про шаблон рассказали,а почему его выгоднее использовать не особо понятно)))
Если использовать сеттеры что бы создать объект с 10 полями нужно 11 строчек кода, используюя билдер, можно создать все в одну строчку - new PersonBuilderImpl().setFirst().setSecond.setThird()....build()
@@husivm Значит мы все сводим к компактности и читабельности кода? (Имею ввиду что это не быстрее, не эффективнее по памяти и тд)
@@МаксимКаторгин-р5у да
@@husivm А как часто этот паттерн применяется на практике? Ну актуален он я так понимаю будет в POJO. Так что тогда лучше, использовать паттерн Builder + структуру POJO или всё таки конфигурацию IoC вместе с их адаптивными моделями, которые не требуют создания экземпляров по всему проекту? В плане простоты. Если мы уж берём этот патерн для простоты и читабельности.
на практике - если у Вас много конструкторов, которые можно заменить билдером, используете билдер
Скажите пожалуйста, можно ли сейчас приобрести Ваши уроки по Spring?
Судя по другому ролику, смысл в том, что основной класс является immutable, т.е. неизменяемым - нельзя через сеттеры задавать новые значения полям - только через конструкторы, которых будет слишком много
А на примере автора можно просто создать сеттеры и не страдать чушью, типа "теперь мы можем заполнить свойства объекта в одну строчку"
Тут билдер больше нужен, если у вас множество полей, но вы не все их хотите заполнять или разное их сочетание. И в целом можно обойтись конструктором, но вы явно будете прописывать null. А с помощью билдера вы собираете нужные вам поля и создаете класс. Но соглашусь, что то, как это подано у автора, можно спокойно воспользоваться сеттерами.
Всё верно. Смысл в том, что объект иммутабельный, а у автора, кроме того, что можно воспользоваться просто сетерами, так и нарушена инкапсуляция так как поля не закрытые. Понятно, что это сделано для примера, но всё равно, так делать нельзя даже в примерах. Это базовая, фундаментальная вещь, которая должна быть всегда.
В Вашем коде можно напрямую обращаться к полям класса Person или cделать сеттеры в классе Person. В чем смысл?
Ну во первых я пишу все в одном файле для наглядности и не разбиваю на разные файлы и пакеты и не ставлю private для экономии времени, а во вторых даже если вы будете сетить каждое поле в отдельной строчке то что бы создать объект с 10 полями нужно 11 строчек кода, а используюя билдер можно создать все в одну строчку - new PersonBuilderImpl().setFirst().setSecond.setThird()....build()
Передаю привет аннотации @Builder из ламбока.
Ну тут показывается как это реализуется под капотом, тоже полезно самим написать.
@@alias77799 да, 10 мес назад я и не дооценивал полезность ролика.
Очень хорошее объяснение!
Хороший, важный паттерн! Знакомые конструкции из андроид-разработки
на каком языке?
@@Das.Kleine.Krokodilна русском
@@megawow2295 1cник?
Стоит ли использовать builder в случае если нужно проверять параметры при создании экземпляра на согласованность? Например есть класс "Регион". У него есть столица/региональный центр и просто города. По очевидным причинам, региональный центр должен лежать во множестве городов, площадь региона не должна быть меньше суммы площадей населённых пунктов и.т.д. Хотелось бы отлавливать неправильно переданные комбинации параметров, но при этом не делать этого в основном конструкторе. Если возможно, то как это можно сделать?
А если нужно обязательно указывать, например, имя?
Можно сделать конструктор PersonBuilderImpl с нужными параметрами. Таким образом пользователь будет обязан ввести значение поля в конструкторе, иначе он не сможет создать Builder
Что для тебя как разработчику удобнее оказалось, win, *nix или macOS?
одинаково, мак красивый, убунта глючит поэтому предпочитаю минт, а так легко работаю на любой ОС и особо разницы не замечаю
А вобще у меня сейчас на работе линукс, дома винда, а видео записываю на маке потому что его можно взять в коворкинг, работаю на всем и разницы не особо замечаю
А почему не вылетает исключение при выводе неинициализированной переменной? Откуда значение по умолчанию берётся?
Ты путаешь с объектами и NullPointerException
У примитивных типов есть значение по умолчанию
А как засетать значения юзеру(в методе у билдера), если нет сетеров у него, я имею ввиду, что поля юзера будут приватными в реальной программе и дав ему сетеры, то это лишает смысла этого паттерна, как быть тогда ?
Нет, сеттеры не лишают смысла, суть паттерна в том что если у тебя много поелей, и тебе надо их сетить через конструктор, при этом ты не знаешь какие поля будут сетиться, ты создашь миллион констукторов, что бы этого не делать, можно использовать паттерн билдер, при этом можно спокойно иметь сеттеры и геттеры и любой другой код который использует эти поля
@@husivm понял, спасибо, например в реализации с nested классом(либо у Вас/Джошуа Блох(Effective java), там нет сеттеров и поля вообще финальные, и насколько я понял объект получается immutable, мы один раз сбилдали и всё, либо можно не возвращать новый объект(внешнего класса), а сделать композицией и возращать новый, только если этот налл, это к примеру если нужно что-то перезасетать в объект после создания
в питоне, кстати, подобные вещи решаются именованными аргументами
я смотрю, и в котлине тоже есть такое
А хіба анотація @Builder з lombok, не робить те саме?
Робить, но якби я показав просто анотицію, булоб не так зрозуміло. Дотого ж Ломбок не на всіх проектах використовуэться
эм, уже были же уроки по паттернам, что поменялось?
а почему методы интерфейса PersonBuilder (кроме метода build) нельзя сделать void ? Почему они должны возвращать PersonBuilder ?
чтобы засетать все параметры в одну строку. Если метод будет void, то мы не получим объект, к которому после точки можно дописывать следующие сеттеры по цепочке.
Method chaining
Чтобы объект возвращал сам себя и можно было цепочкой сетапить данные по типу obj.name('Max').surname('Brown').build(); и только build() возвращает сам объект
Просто Мега супер огонь чотко)
И тебя взяли на работу в Лос-Анджелес? Втф мен!?
Что не так?
верните уроки по спрингу за деньги!!!
верните уроки по спрингу - но бесплатно! С меня лайки на все 400+ видео.