Почему шаблон Java Builder поверх шаблона Java Bean

Question

Почему шаблон Java Builder поверх шаблона Java Bean

1

В Effective Java от Joshua Bloch было предложено, что если мы столкнулись со сценарием, в котором у нас много полей в нашем компоненте, мы должны рассмотреть возможность использования компоновщика Builder над телескопическим или java-компонентом. Прочитав пояснительную выдержку из книги, я наткнулся на термин "инвариант". Я думал о многих случаях инвариантов, но не мог подумать о том, что мы не можем заставить пользователя использовать необходимые поля, связанные с инвариантностью, предоставляя им только конструктор такой сигнатуры. Но хорошо ли делать такие вещи? Какую инвариантность мы можем использовать в шаблоне строителя, чтобы гарантировать, что мы используем шаблон, когда мы требуемся, а не только ради него.

Sourabh 18 март 2014, в 08:09

Источник

Теги:

java

design-patterns

design

1 ответ

Ещё вопросы

fge · Accepted Answer · 2014-03-18T04-00-00.000Z

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

Это правда. Однако это может быть хорошо, если у вас есть 3, может быть, 4 аргумента. Начиная с 5, ваш конструктор начнет очень долго.

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

Сам строитель не имеет инвариантов; он изменен, не является потокобезопасным. Однако он может генерировать классы с большим количеством инвариантов. Неизменяемые классы, даже; и у них есть много преимуществ (они, например, по сути потокобезопасны).

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

Не говоря уже о том, что если у вас есть несколько конструкторов, вам, вероятно, придется дублировать проверки. С помощью строителя вам нужно будет только сделать эти проверки один раз - в соответствующем .with*() методе.

fge ==> Я согласен по большей части с генерацией неизменяемых классов и потоковобезопасных классов с использованием паттерна Builder, но даже при всей наивности это может показаться, что я все еще немного путаюсь с термином инвариант, что именно является инвариантом в бине? Является ли это зависимостью одного поля от другого поля, поэтому если мы инициализируем зависимое поле перед зависимостью, то это приведет к недопустимому состоянию?
Инвариант экземпляра - это поле, которое никогда не изменится в течение жизни этого экземпляра. В бобе фактически нет никаких инвариантов ... По крайней мере, в "чистых" бобах.
Что касается полевых зависимостей, если вы используете компоновщик, вы можете проверить такие зависимости, когда вы .build ()
Хорошо ... спасибо большое ... его простой инвариант (который не меняется). Спасибо за красивое объяснение.
В некоторых из моих проектов я даже продвинулся дальше, используя то, что я называю «заморозка / оттаивание» -> я могу генерировать компоновщики из неизменных экземпляров и обратно, и это два очень, очень простых интерфейса
and avoid all these checks in the constructor - я немного консервативен в этом, что если я создам экземпляр класса, используя отражение?
Но очень редко можно вручную заморозить объект до полной реализации и не дать пользователю использовать его. Можете ли вы поделиться интерфейсом вашего замораживания / оттаивания?
@SvetlinZarev ммм, не делай этого? ;) Обратите внимание, что даже с библиотеками десериализации (это делает Джексон) вы можете использовать сборщики, если хотите.
Спасибо, я обязательно изучу это. :)
@SvetlinZarev в более широком смысле, хотя я почти никогда не использую рефлексию и бины, и когда я десериализую, я десериализую классы достаточно просто, поэтому мне не нужны проверки аргументов конструктора; в конечном счете, это вопрос вкусов
@fge Я согласен с тобой, и все же это заставляет меня вздрогнуть :) Кстати, насколько я помню, в книге было написано, что проверка должна проводиться и в конструкторе, помимо сборщика, или я ошибаюсь?