Чому ланцюжок сетерів нетрадиційний?

Ведення ланцюга на бобах дуже зручно: не потрібно перевантажувати конструкторів, мегаконструкторів, заводів, а також підвищує читабельність. Я не можу придумати жодних недоліків, якщо ви не хочете, щоб ваш об’єкт був непорушним , і в такому випадку у нього все одно не було б ніяких сетерів. Тож є причина, чому це не конвенція ООП?

public class DTO {

    private String foo;
    private String bar;

    public String getFoo() {
         return foo;
    }

    public String getBar() {
        return bar;
    }

    public DTO setFoo(String foo) {
        this.foo = foo;
        return this;
    }

    public DTO setBar(String bar) {
        this.bar = bar;
        return this;
    }

}

//...//

DTO dto = new DTO().setFoo("foo").setBar("bar");

Тож є причина, чому це не конвенція ООП?

Моя найкраща здогадка: тому що це порушує CQS

У вас є команда (зміна стану об’єкта) та запит (повернення копії стану - в даному випадку самого об’єкта), змішані в один і той же метод. Це не обов'язково є проблемою, але воно порушує деякі основні вказівки.

Наприклад, в C ++, std :: stack :: pop () - це команда, яка повертає void, а std :: stack :: top () - це запит, який повертає посилання на верхній елемент у стеку. Класично ви хотіли б поєднати ці два, але ви не можете цього зробити і бути безпечними для винятків. (Не проблема в Java, тому що оператор присвоєння Java не кидає).

Якби DTO був типом значення, ви можете досягти подібного кінця з

public DTO setFoo(String foo) {
    return new DTO(foo, this.bar);
}

public DTO setBar(String bar) {
    return new DTO(this.foo, bar);
}

Крім того, пов'язані значення повернення є колосальним болем у справі, коли ви маєте справу зі спадщиною. Дивіться "Цікаво повторюваний шаблон шаблону"

Нарешті, виникає проблема, що конструктор за замовчуванням повинен залишити вас об’єктом, який знаходиться у дійсному стані. Якщо вам потрібно виконати купу команд, щоб відновити об'єкт у дійсному стані, щось вийшло дуже неправильно.

1. Збереження кількох натискань клавіш не є переконливим. Це може бути приємно, але конвенції OOP більше дбають про концепції та структури, а не натискання клавіш.

2. Повертається значення безглуздо.

3. Навіть більше ніж безглуздо, повернене значення вводить в оману, оскільки користувачі можуть очікувати, що повернене значення має значення. Вони можуть сподіватися, що це "непорушний сетер"

   public FooHolder {
       public FooHolder withFoo(int foo) {
           /* return a modified COPY of this FooHolder instance */
       }
   }

   Насправді ваш сетер мутує об'єкт.

4. Це не добре справляється зі спадщиною.

   public FooHolder {
       public FooHolder setFoo(int foo) {
           ...
       }
   }

   public BarHolder extends FooHolder {
       public FooHolder setBar(int bar) {
           ...
       }
   } 

   Я можу писати

   new BarHolder().setBar(2).setFoo(1)

   але ні

   new BarHolder().setFoo(1).setBar(2)

Для мене важливі з 1 по №3. Добре написаний код - це не про приємно оформлений текст. Добре написаний код - про основні поняття, взаємозв'язки та структуру. Текст - це лише зовнішнє відображення справжнього значення коду.

Я не думаю, що це конвенція OOP, вона більше пов'язана з мовним дизайном та його умовами.

Здається, вам подобається використовувати Java. У Java є специфікація JavaBeans, яка вказує тип повернення сеттера, який повинен бути недійсним, тобто він суперечить ланцюгу сетерів. Ця специфікація широко прийнята та впроваджена у різноманітних інструментах.

Звичайно, ви можете запитати, чому не є ланцюжком частини специфікації. Я не знаю відповіді, можливо, ця модель просто не була відома / популярна в той час.

Як говорили інші, це часто називають вільним інтерфейсом .

Зазвичай сеттери - це передача викликів змінних у відповідь на логічний код у програмі; ваш клас DTO є прикладом цього. Звичайний код, коли сетери нічого не повертають, це найкраще для цього. Інші відповіді пояснили так.

Однак є кілька випадків, коли вільний інтерфейс може бути хорошим рішенням, вони мають спільне.

• Константи в основному передаються сетерам
• Логіка програми не змінює те, що передається сеттерам.

Налаштування конфігурації, наприклад, вільно-нібернат

Id(x => x.Id);
Map(x => x.Name)
   .Length(16)
   .Not.Nullable();
HasMany(x => x.Staff)
   .Inverse()
   .Cascade.All();
HasManyToMany(x => x.Products)
   .Cascade.All()
   .Table("StoreProduct");

Налаштування тестових даних в одиничних тестах за допомогою спеціальних класів TestDataBulderClasses (Object Mothers)

members = MemberBuilder.CreateList(4)
    .TheFirst(1).With(b => b.WithFirstName("Rob"))
    .TheNext(2).With(b => b.WithFirstName("Poya"))
    .TheNext(1).With(b => b.WithFirstName("Matt"))
    .BuildList(); // Note the "build" method sets everything else to
                  // senible default values so a test only need to define 
                  // what it care about, even if for example a member 
                  // MUST have MembershipId  set

Однак створити хороший вільний інтерфейс дуже важко , тому варто лише тоді, коли у вас є багато "статичних" налаштувань. Також вільний інтерфейс не слід змішувати з "нормальними" класами; отже, часто використовується модель конструктора.

Думаю, що причина в тому, що це не звичайний спосіб ланцюга одного сетера за іншим, полягає в тому, що для цих випадків характерніше бачити об'єкт параметрів або параметри в конструкторі. C # також має синтаксис ініціалізатора.

Замість:

DTO dto = new DTO().setFoo("foo").setBar("bar");

Можна написати:

(в JS)

var dto = new DTO({foo: "foo", bar: "bar"});

(в C #)

DTO dto = new DTO{Foo = "foo", Bar = "bar"};

(на Java)

DTO dto = new DTO("foo", "bar");

setFooі setBarвони більше не потрібні для ініціалізації та можуть бути використані для мутації пізніше.

Хоча ланцюговість корисна в деяких обставинах, важливо не намагатися складати все в один рядок лише заради скорочення символів нового рядка.

Наприклад

dto.setFoo("foo").setBar("fizz").setFizz("bar").setBuzz("buzz");

ускладнює читання та розуміння того, що відбувається. Переформатування на:

dto.setFoo("foo")
    .setBar("fizz")
    .setFizz("bar")
    .setBuzz("buzz");

Це набагато простіше зрозуміти і робить "помилку" в першій версії більш очевидною. Після відновлення коду до цього формату немає реальної переваги перед:

dto.setFoo("foo");
dto.setBar("bar");
dto.setFizz("fizz");
dto.setBuzz("buzz");

Ця техніка фактично використовується в шаблоні Builder.

x = ObjectBuilder()
        .foo(5)
        .bar(6);

Однак загалом цього уникають, оскільки це неоднозначно. Не очевидно, чи є повернутим об'єктом об'єкт (тому ви можете зателефонувати іншим сеттерам), чи повернутий об'єкт - це значення, яке було щойно призначене (також загальний шаблон). Відповідно, "Принцип найменшого сюрпризу" пропонує вам не намагатися припускати, що користувач хоче бачити те чи інше рішення, якщо це не є основоположним для дизайну об'єкта.

Це скоріше коментар, ніж відповідь, але я не можу коментувати, так що ...

я просто хотів зазначити, що це питання мене здивувало, тому що я взагалі не вважаю це незвичайним . Насправді в моєму середовищі роботи (веб-розробник) дуже дуже часто.

Наприклад, таким чином є вчення Symfony: create: elements команда автоматично генерує все setters , за замовчуванням .

jQuery свого роду ланцюжок більшості своїх методів дуже схожий спосіб.