История изменений
Исправление vbr, (текущая версия) :
Ладно, распишу ВРЁТИ по пунктам.
Нет, это какая-то пародия на шаблон билдер в задумке потокобезопасный, но с такой реализацией нет.
Во-первых про потокобезопасность я не писал совсем ничего.
Во-вторых билдер потокобезопасным делать - ну можно, наверное, но это очень странная затея. Потокобезопасным делают сконструированный объект. И в данном примере он таки получился потокобезопасным. Если ты с этим не согласен - укажи подробней.
private Integer age;
Плюс распаковка пустой оболочки приведёт к nullpointerexception
В этом примере нет распаковки пустой оболочки. Она оборачивается в Optional и nullpointerexception там нигде не появится.
this.name = requireNonNull(name);
А это даже не скомпилится.
Вот исходный код стандартного метода Objects.requireNonNull:
public static <T> T requireNonNull(T obj) {
if (obj == null)
throw new NullPointerException();
return obj;
}
Какие именно проблемы с компиляцией ты тут видишь?
Хочется клонов, то почему не реализовать интерфейс Cloneable и соотвествующий метод интерфейса?
Во-первых интерфейс Cloneable вообще не про это. И в современном коде почти нигде не используется.
Во-вторых это пустой интерфейс-маркер. У него нет никакого соответствующего метода. Вероятно ты имел в виду метод Object.clone.
В-третьих реализовывать его обычно не надо. Java его сама умеет реализовывать.
В-четвёртых это вообще был понятный минимальный пример, на котором я показал неудобство такого билдера.
Если говорить про то, как копирование надо делать на практике - надо сделать метод Person.update(), который вернёт инициализированный текущими значениями Builder и потом сделать пустой build(). Т.е. var personCopy = person.update().build()
. Хотя для иммутабельного объекта смысла в таком действии немного.
Исходная версия vbr, :
Ладно, распишу ВРЁТИ по пунктам.
Нет, это какая-то пародия на шаблон билдер в задумке потокобезопасный, но с такой реализацией нет.
Во-первых про потокобезопасность я не писал совсем ничего.
Во-вторых билдер потокобезопасным делать - ну можно, наверное, но это очень странная затея. Потокобезопасным делают сконструированный объект. И в данном примере он таки получился потокобезопасным. Если ты с этим не согласен - укажи подробней.
private Integer age;
Плюс распаковка пустой оболочки приведёт к nullpointerexception
В этом примере нет распаковки пустой оболочки. Она оборачивается в Optional и nullpointerexception там нигде не появится.
this.name = requireNonNull(name);
А это даже не скомпилится.
Вот исходный код стандартного метода Objects.requireNonNull:
public static <T> T requireNonNull(T obj) {
if (obj == null)
throw new NullPointerException();
return obj;
}
Какие именно проблемы с компиляцией ты тут видишь?
Хочется клонов, то почему не реализовать интерфейс Cloneable и соотвествующий метод интерфейса?
Во-первых интерфейс Cloneable вообще не про это. И в современном коде почти нигде не используется.
Во-вторых это пустой интерфейс-маркер. У него нет никакого соответствующего метода. Вероятно ты имел в виду метод Object.clone.
В-третьих реализовывать его обычно не надо. Java его сама умеет реализовывать.
В-четвёртых это вообще был понятный минимальный пример, на котором я показал неудобство такого билдера.