Почему цепные сеттеры нетрадиционны?

Реализация цепочки на bean-компонентах очень удобна: нет необходимости перегружать конструкторы, мега-конструкторы, фабрики и обеспечивает повышенную читаемость. Я не могу думать о минусах, если только вы не хотите, чтобы ваш объект был неизменным , и в этом случае у него все равно не было бы сеттеров. Так есть ли причина, по которой это не соглашение об ООП?

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. Сохранение нескольких нажатий клавиш не является обязательным. Это может быть хорошо, но соглашения ООП больше заботятся о концепциях и структурах, а не о нажатиях клавиш.

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 являются важными. Хорошо написанный код не о приятном расположении текста. Хорошо написанный код о фундаментальных понятиях, отношениях и структуре. Текст - это только внешнее отражение истинного значения кода.

Я не думаю, что это соглашение ООП, оно больше связано с дизайном языка и его соглашениями.

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

Конечно, вы можете спросить, почему это не является частью спецификации. Я не знаю ответа, возможно, этот шаблон просто не был известен / популярен в то время.

Как говорили другие люди, это часто называют свободным интерфейсом .

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

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

• Константы в основном передаются сеттерам
• Программная логика не меняет то, что передается сеттерам.

Настройка конфигурации, например, fluent-nhibernate

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: генерирует: entity команда автоматически генерирует все setters , по умолчанию .

JQuery объединяет большинство своих методов очень похожим образом.