Недостатки шаблона проектирования строителя

Ответ 1

Он создает больше кода (и может ввести более сложную) в DTO, чем если бы у вас были, например, аргументы конструктора и/или сеттеры/геттеры.

По-моему, это неважно, в большинстве случаев не так много дополнительного кода. Шаблон построителя будет более чем стоить, если у вас есть объект, который имеет некоторые обязательные и некоторые необязательные параметры.

Ответ 2

Образец является лишь невыгодным, когда шаблон подвергается злоупотреблениям/злоупотреблениям. То есть модель не решила/не удовлетворила фактическую техническую/функциональную проблему вообще. Затем вы должны искать другой шаблон для решения конкретной проблемы.

Это не относится к шаблону строителя, но для разработки шаблонов в целом.

Обновить: если вам интересно узнать о различных шаблонах дизайна (в частности, упомянутых в книге шаблонов дизайна GoF) и примерах реального мира в Java API, то вы можете найти этот ответ: Примеры шаблонов дизайна GoF в основных библиотеках Java. Он содержит ссылки на статьи в Википедии, подробно описывающие шаблоны.

Ответ 3

I второй Jarle post.

Иначе, когда дело доходит до недостатков:

• Образец компоновщика не подходит, если вам нужно сопоставить DTO с, например, спящим или JAXB.
• Если вы по каким-то причинам хотите изменить объект.
• Для небольших DTO с двумя или тремя полями это просто накладные расходы, и вы должны использовать конструктор или два. Если вы не знаете/не верьте, что DTO будет содержать больше полей в будущем.

Ответ 4

Рисунок Builder, когда используется идея, чтобы преодолеть отсутствие необязательных параметров в Java, вы теряете статический анализ, предоставляемый компилятором (и все хорошие функции рефакторинга, предоставляемые вашей IDE). Это означает, что вы обнаружите, что некоторые обязательные параметры отсутствуют только во время выполнения, вместо того, чтобы ваша IDE сразу сообщила вам, что что-то не так...

Ответ 5

по сравнению с конструкторами телескопов

• потеря статического анализа
• для отсутствия обязательных параметров и исключение нужно бросить и поймать somethere
• если вы используете в сборке типы с коробочными типами, чтобы представить примитивные значения, которые еще не установлены, тогда происходит много автоматического бокса/распаковки - что позволяет NullPointerExceptions, которые трудно обнаружить. Нет таких проблема в конструкторах телескопа - вы можете просто передать примитив значения.
• намного больше кода

Ответ 6

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