Шаблон построителя и объект конфигурации

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

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

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

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, очень либерально и очень хорошо используются «плавные интерфейсы» . Я бы выбрал их в любой день по сравнению с вашим подходом «легче вводить / меньше символов» :)

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

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

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

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

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

Может быть, нам нужно изобрести предложение WITH: пример, допустим, у вас есть

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, который можно использовать в фреймворках ...

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

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

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

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

Кто мы такие, чтобы подражать этому?

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

Вы рассматривали возможность использования builder-builder?

Мне кажется, что builder (с префиксами типа "With") читается более естественно/легко.

IMO, шаблон построителя намного надежнее, если у вас есть такие вещи, как проверка и т. Д.

Шаблон построителя в вашем случае можно изменить следующим образом:

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

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

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

Разница между конструктором и «объектом конфигурации» (кажется, хорошее название) заключается в том, что вам все равно нужно создать объект с теми же параметрами с помощью конструктора или получателя / установщика. Это а) не решает проблему конструктора или б) сохраняет объект конфигурации в несогласованном состоянии. Несогласованные состояния объекта конфигурации на самом деле не повредят ему, но вы можете передать незаконченный объект конфигурации в качестве параметра. [Кажется, что ссылка Michid на фантомные типы решает эту проблему, но это снова убивает читабельность ( new Foo вроде как отстой).] Вот и все. Большое преимущество шаблона построителя: вы можете проверить свои параметры перед созданием объекта и , вы можете вернуть любой подтип (действует как фабрика).

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