Builder pattern vs. config object

Question

Шаблон строителя популярен для создания неизменяемых объектов, но для создания строителя есть некоторые накладные расходы на программирование. Поэтому я удивляюсь, почему бы просто не использовать объект конфигурации.

Использование строитель будет выглядеть следующим образом:

Product p = Product.name("Vodka").alcohol(0.38).size(0.7).price(17.99).build(); 

Очевидно, что это очень читаемым и лаконичным, но вы должны реализовать строитель:

public class Product { 

    public final String name; 
    public final float alcohol; 
    public final float size; 
    public final float price; 

    private Product(Builder builder) { 
     this.name = builder.name; 
     this.alcohol = builder.alcohol; 
     this.size = builder.size; 
     this.price = builder.price; 
    } 

    public static class Builder { 

     private String name; 
     private float alcohol; 
     private float size; 
     private float price; 

     // mandatory 
     public static Builder name(String name) { 
      Builder b = new Builder(); 
      b.name = name; 
      return b; 
     } 

     public Builder alcohol(float alcohol) { 
      this.alcohol = alcohol; 
      return.this; 
     } 

     public Builder size(float size) { 
      this.size = size; 
      return.this; 
     } 

     public Builder price(float price) { 
      this.price = price; 
      return.this; 
     } 

     public Product build() { 
      return new Product(this); 
     } 

    } 

} 

Моя идея заключается в том , чтобы уменьшить код с помощью простого объекта конфигурации следующим образом:

class ProductConfig { 

     public String name; 
     public float alcohol; 
     public float size; 
     public float price; 

     // name is still mandatory 
     public ProductConfig(String name) { 
      this.name = name; 
     } 

} 

public class Product { 

    public final String name; 
    public final float alcohol; 
    public final float size; 
    public final float price; 

    public Product(ProductConfig config) { 
     this.name = config.name; 
     this.alcohol = config.alcohol; 
     this.size = config.size; 
     this.price = config.price; 
    } 

} 

Использование:

ProductConfig config = new ProductConfig("Vodka"); 
config.alcohol = 0.38; 
config.size = 0.7; 
config.price = 17.99; 
Product p = new Product(config); 

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

Есть ли недостаток в настройке конфигурации, который я забыл?

Answer 1

Образец компоновщика улучшает развязку - ваш Продукт может быть интерфейсом, и единственный класс, который знает о реализации (или реализации, в некоторых случаях), является строителем. Если строитель также реализует интерфейс, вы можете ввести его в свой код, чтобы увеличить развязку.

Эта развязка означает, что ваш код более удобен в обслуживании и проще в тестировании.

Answer 2

IMO, шаблон строитель гораздо roboust, если у вас есть такие вещи, как проверка и т.д.

Узор строитель в вашем случае может быть изменен, чтобы сделать следующее:

Product p = new ProductBuilder("pName").alcohol(0.38).size(0.7).price(17.99).build(); 

build() метод может делать все материалы проверки, необходимые для вашего строителя. У шаблона строителя также есть несколько проектных авангардов (все из которых могут быть неприменимы в вашем случае). Для deatils отметьте это question

Answer 3

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

Answer 4

Какую проблему вы пытаетесь решить с помощью своего шаблона? Шаблон построителя используется для объектов со многими (необязательными) параметрами, чтобы предотвратить тонны разных конструкторов или очень длинные. Он также сохраняет ваш объект в согласованном состоянии (по сравнению с javabean pattern) во время строительства.

Разница между конструктором и «конфигурационным объектом» (похоже, что это хорошее имя) заключается в том, что вам все равно нужно создать объект с теми же параметрами с помощью конструктора или getter/setter. Это а) не решает проблему конструктора или б) сохраняет объект конфигурации в несогласованном состоянии. Несогласованные состояния объекта config действительно не повредит его, но вы можете передать незавершенный объект конфигурации в качестве параметра. [Ссылка Michids на типы фантомов, похоже, решает эту проблему, но это снова убивает читаемость (kinda sucks).] Thats большое преимущество шаблона строителя: вы можете проверить свои параметры перед тем, как создать объект и, вы можете вернуть любой подтип (действует как фабрика).

Конфигурационные объекты действительны для наборов параметров, которые являются обязательными. Я видел этот шаблон много раз в .NET или Java раньше.

Answer 5

Считаете ли вы использование builder-builder?

Я думаю, что строитель (с префиксами типа «С») читает более натружно/плавно.

Answer 6

Вы теряете несколько преимуществ рисунка строителя, как уже указывалось ( является уродливым и сложным для обслуживания и утечки деталей по сравнению с чистым строителем).

То, что я пропустил больше всего, состоит в том, что шаблон строителя можно использовать для обеспечения так называемого «Свободных интерфейсов».

Вместо этого:

ProductConfig config = new ProductConfig("Vodka"); 
config.alcohol = 0.38; 
config.size = 0.7; 
config.price = 17.99; 
Product p = new Product(config); 

Вы можете сделать:

ProductFactory.create() 
    .drink("Vodka") 
    .whereAlcohoolLevelIs(0.38) 
    .inABottleSized(0.7) 
    .pricedAt(17.99) 
    .build(); 

Не все, как беглые интерфейсы, но они, безусловно, очень хорошим использование шаблона строителя (все беглые интерфейсы должны использовать шаблон строителя, но не все шаблоны построителя - это плавные интерфейсы).

Некоторые отличные коллекции Java, такие как коллекции Google, делают как очень либеральное, так и очень хорошее использование «Свободные интерфейсы». Я бы выбрал их в любой день над вашим «более простые в использовании/менее символы» подход:)

Answer 7

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

Вы используете простой объект значения для хранения нескольких аргументов, которые нужны функции (/ method/constructor), нет ничего плохого в этом, это было сделано целую вечность. Пока мы не называем необязательные параметры, нам придется разрабатывать обходные пути, подобные этому, - это позор, а не какое-то чертовски блестящее изобретение богов на Солнце.

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

Кто мы такие, чтобы имитировать?

Answer 8

Я лично считаю, что шаблон строителя с первого взгляда предлагает вам более чистый код, где эти объекты фактически используются. С другой стороны, отсутствие геттеров/сеттеров не будет очень полезно для многих фреймворков, которые ожидают геттеры/сеттеры для верблюда. Это серьезный откат, который я чувствую.

Что мне также нравится с геттерами/сеттерами, так это то, что вы четко видите, что вы делаете: получите или установите. Я чувствую себя со строителем, я теряю немного интуитивной ясности здесь.

Я знаю, что многие люди прочитали определенную книгу, и теперь внезапно модель строителя наслаждалась шумихой, как будто это был новый iPhone. Однако я не являюсь ранним усыновителем. Я использую только «новый способ», когда он действительно действительно демонстрирует большую экономию времени на любой территории, будь то производительность, техническое обслуживание, кодирование ...

Практическое применение - это то, что я обычно лучше с геттерами/сеттеров и конструкторов. Это позволяет мне повторно использовать эти POJO для любых целей.

Хотя я вижу цель вашего объекта конфигурации, я также думаю, что это еще больше накладных расходов, чем строитель, и для чего? Что не так с сеттерами?

Может быть, нам нужно придумать спецификаторе: примера, скажем, у вас есть

public Class FooBar() { 
    private String foo; 

    public void setFoo(String bar) { 
     this.foo = bar; 
    } 

    public String getFoo() { 
     return this.foo; 
    } 
} 

public static void main(String []args) { 

FooBar fuBar = new FooBar(); 
String myBar; 

with fuBar { 
    setFoo("bar"); 
    myBar = getFoo(); 
} 
} 

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

Это не выглядит так же чисто, как использование объекта с помощью строителя, но вы сохраняете время построения строителя. И вы все еще можете использовать этот класс в качестве обычного pojo/bean, который может использоваться в фреймах ...

Вы, ребята, действительно хотели бы эту статью или думаете, что это скорее сосать? Cheers

Answer 9

Шаблон конфигурации и шаблон строителя функционально эквивалентны. Они оба решают одни и те же проблемы -

• Устранение необходимости в нескольких подписей конструктора

• Разрешить поля быть установлены только во время строительства

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

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