недостатки шаблона разработки разработчика [закрываются]
3 ответа
Это действительно создает больше кода (и может привнести больше сложности) в DTO, чем если бы у вас были, например, аргументы конструкторов и/или сеттеры/геттеры.
На мой взгляд, это не так уж и важно, в большинстве случаев лишнего кода не так уж и много. Паттерн builder будет более чем полезен, если у вас есть объект, который имеет несколько обязательных и несколько необязательных параметров.
Шаблон является невыгодным только тогда, когда шаблоном злоупотребляют / неправильно используют. Т.е. шаблон вообще не решал / не соответствовал реальной технической / функциональной проблеме. Затем вам следует поискать другой шаблон для решения конкретной проблемы.
Это не относится конкретно к шаблону построителя, но к шаблонам проектирования в целом.
Обновление : если вам интересно узнать о различных шаблонах дизайна (в частности, упомянутых в книге GoF Design Patterns) и реальных примерах в Java API, вы можете найти этот ответ: Полезны примеры шаблонов проектирования GoF в основных библиотеках Java . Он содержит ссылки на статьи Википедии, в которых подробно объясняются закономерности.
Иначе, когда дело доходит до недостатков:
- Шаблон построителя не подходит, если вам нужно сопоставить DTO, например, с Hibernate или JAXB.
- Если вам по каким-то причинам нужен изменяемый объект.
- Для небольших DTO с двумя или тремя полями это просто накладные расходы, и вам лучше использовать конструктор или два. Если вы не знаете / не верите, что DTO будет содержать больше полей в будущем.