Это плохая практика, чтобы заставить сеттер возвращать «это»?

Это хорошая или плохая идея, чтобы сеттеры в java возвращали "this"?

public Employee setName(String name){
   this.name = name;
   return this;
}

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

list.add(new Employee().setName("Jack Sparrow").setId(1).setFoo("bacon!"));

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

Employee e = new Employee();
e.setName("Jack Sparrow");
...and so on...
list.add(e);

... но это как бы идет вразрез со стандартным соглашением. Я полагаю, что это может стоить того, потому что это может заставить этого сеттера сделать что-то еще полезное. Я видел, как в этом шаблоне использовались некоторые места (например, JMock, JPA), но он кажется необычным, и обычно используется только для очень четко определенных API, где этот шаблон используется везде.

Обновить:

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

Я не думаю, что с этим что-то конкретно не так, это просто вопрос стиля. Это полезно, когда:

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

Альтернативы этому методу могут быть:

1. Один мега-конструктор (недостаток: вы можете передавать множество нулевых значений или значений по умолчанию, и становится трудно понять, какое значение соответствует чему)
2. Несколько перегруженных конструкторов (недостаток: становится громоздким, если у вас их несколько)
3. Фабричные / статические методы (обратная сторона: то же, что перегруженные конструкторы - становится громоздким, когда их несколько)

Если вы собираетесь установить только несколько свойств одновременно, я бы сказал, что возвращать «this» не стоит. Конечно, он падает, если позже вы решите вернуть что-то еще, например, индикатор состояния / успеха / сообщение.

Это не плохая практика. Это все более распространенная практика. Большинство языков не требуют от вас иметь дело с возвращенным объектом, если вы не хотите, чтобы он не изменял синтаксис «нормального» использования сеттера, но позволял вам связывать сеттеры вместе.

Это обычно называется шаблоном компоновщика или свободным интерфейсом .

Это также распространено в Java API:

String s = new StringBuilder().append("testing ").append(1)
  .append(" 2 ").append(3).toString();

Подвести итоги:

• это называется «плавным интерфейсом» или «цепочкой методов».
• это не "стандартная" Java, хотя в наши дни вы видите ее более (прекрасно работает в jQuery)
• он нарушает спецификацию JavaBean, поэтому он порвет с различными инструментами и библиотеками, особенно сборщиками JSP и Spring.
• это может предотвратить некоторые оптимизации, которые JVM обычно делает
• некоторые люди думают, что это очищает код, другие думают, что это «ужасно»

Пара других моментов, не упомянутых:

• Это нарушает принцип, что каждая функция должна делать одну (и только одну) вещь. Вы можете или не можете в это поверить, но я думаю, что в Java это работает хорошо.

• IDE не собираются создавать их для вас (по умолчанию).

• И наконец, вот реальная точка данных. У меня были проблемы с использованием библиотеки, созданной следующим образом. Конструктор запросов Hibernate является примером этого в существующей библиотеке. Так как методы set * в Query возвращают запросы, невозможно определить, просто используя сигнатуру, как ее использовать. Например:

  Query setWhatever(String what);

• Он вводит неоднозначность: изменяет ли метод текущий объект (ваш шаблон) или, возможно, Query действительно неизменен (очень популярный и ценный шаблон), а метод возвращает новый. Это просто затрудняет использование библиотеки, и многие программисты не используют эту функцию. Если бы сеттеры были сеттерами, было бы понятнее, как их использовать.

Я предпочитаю использовать методы with для этого:

public String getFoo() { return foo; }
public void setFoo(String foo) { this.foo = foo; }
public Employee withFoo(String foo) {
  setFoo(foo);
  return this;
}

Таким образом:

list.add(new Employee().withName("Jack Sparrow")
                       .withId(1)
                       .withFoo("bacon!"));

Предупреждение : этот withXсинтаксис обычно используется для предоставления «установщиков» для неизменяемых объектов, поэтому вызывающие эти методы могут разумно ожидать, что они создадут новые объекты, а не изменят существующий экземпляр. Может быть, более разумная формулировка будет что-то вроде:

list.add(new Employee().chainsetName("Jack Sparrow")
                       .chainsetId(1)
                       .chainsetFoo("bacon!"));

С соглашением об именовании chainsetXyz () практически все должны быть счастливы.

Если вы не хотите возвращаться 'this'из установщика, но не хотите использовать второй вариант, вы можете использовать следующий синтаксис для установки свойств:

list.add(new Employee()
{{
    setName("Jack Sparrow");
    setId(1);
    setFoo("bacon!");
}});

Кроме того, я думаю, что это немного чище в C #:

list.Add(new Employee() {
    Name = "Jack Sparrow",
    Id = 1,
    Foo = "bacon!"
});

Он не только нарушает соглашение о методах получения / установки, но также нарушает структуру ссылок на методы Java 8. MyClass::setMyValueэто BiConsumer<MyClass,MyValue>и myInstance::setMyValueесть Consumer<MyValue>. Если у вас есть возвращаемый метод setter this, то он больше не является действительным экземпляром Consumer<MyValue>, а скорее a Function<MyValue,MyClass>, и приведет к тому, что что-либо, использующее ссылки на методы для этих сеттеров (при условии, что они являются пустыми методами), будет повреждено.

Я не знаю Java, но я сделал это на C ++. Другие люди говорили, что это делает строки очень длинными и очень сложными для чтения, но я делал это много раз:

list.add(new Employee()
    .setName("Jack Sparrow")
    .setId(1)
    .setFoo("bacon!"));

Это даже лучше:

list.add(
    new Employee("Jack Sparrow")
    .Id(1)
    .foo("bacon!"));

по крайней мере, я думаю. Но вы можете понизить меня и назвать меня ужасным программистом, если хотите. И я не знаю, разрешено ли вам даже делать это на Java.

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

Поскольку он не возвращает void, он больше не является корректным установщиком свойств JavaBean. Это может иметь значение, если вы один из семи человек в мире, использующих визуальные инструменты Bean Builder, или один из 17, использующих элементы JSP-bean-setProperty.

По крайней мере, теоретически , это может повредить механизмы оптимизации JVM, устанавливая ложные зависимости между вызовами.

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

Вот почему я голосую "нет", не используйте его.

Это совсем не плохая практика. Но это не совместимо с JavaBeans Spec .

И много спецификаций зависит от этих стандартных средств доступа.

Вы всегда можете заставить их сосуществовать друг с другом.

public class Some {
    public String getValue() { // JavaBeans
        return value;
    }
    public void setValue(final String value) { // JavaBeans
        this.value = value;
    }
    public String value() { // simple
        return getValue();
    }
    public Some value(final String value) { // fluent/chaining
        setValue(value);
        return this;
    }
    private String value;
}

Теперь мы можем использовать их вместе.

new Some().value("some").getValue();

Вот еще одна версия для неизменного объекта.

public class Some {

    public static class Builder {

        public Some build() { return new Some(value); }

        public Builder value(final String value) {
            this.value = value;
            return this;
        }

        private String value;
    }

    private Some(final String value) {
        super();
        this.value = value;
    }

    public String getValue() { return value; }

    public String value() { return getValue();}

    private final String value;
}

Теперь мы можем сделать это.

new Some.Builder().value("value").build().getValue();

Если вы используете одно и то же соглашение во всем приложении, кажется, все в порядке.

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

public class NutritionalFacts {
    private final int sodium;
    private final int fat;
    private final int carbo;

    public int getSodium(){
        return sodium;
    }

    public int getfat(){
        return fat;
    }

    public int getCarbo(){
        return carbo;
    }

    public static class Builder {
        private int sodium;
        private int fat;
        private int carbo;

        public Builder sodium(int s) {
            this.sodium = s;
            return this;
        }

        public Builder fat(int f) {
            this.fat = f;
            return this;
        }

        public Builder carbo(int c) {
            this.carbo = c;
            return this;
        }

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

    private NutritionalFacts(Builder b) {
        this.sodium = b.sodium;
        this.fat = b.fat;
        this.carbo = b.carbo;
    }
}

Пауло Абрантес (Paulo Abrantes) предлагает еще один способ беглости установщиков JavaBean: определить внутренний класс построителя для каждого JavaBean. Если вы используете инструменты, которые сбиты с толку сеттерами, которые возвращают значения, шаблон Пауло может помочь.

Я за сеттеров, имеющих «это» возвращение. Мне все равно, если это не бобов. Для меня, если нормально иметь выражение / оператор "=", тогда установщики, которые возвращают значения, в порядке.

Раньше я предпочитал такой подход, но я решил против этого.

Причины:

• Читаемость. Это делает код более читабельным, чтобы каждый setFoo () находился в отдельной строке. Обычно вы читаете код много-много раз, чем один раз, когда пишете его.
• Побочный эффект: setFoo () должен устанавливать только поле foo, больше ничего. Возвращение это лишнее "ЧТО ЭТО было".

Шаблон Builder, который я видел, использует не соглашение setFoo (foo) .setBar (bar), а скорее foo (foo) .bar (bar). Возможно, именно по этим причинам.

Это как всегда дело вкуса. Мне просто нравится подход "меньше всего сюрпризов".

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

PS: Просто подумал оставить это здесь, так как я искал конкретное имя.

На первый взгляд: «Ужасно!».

На дальнейшие мысли

list.add(new Employee().setName("Jack Sparrow").setId(1).setFoo("bacon!"));

на самом деле менее подвержен ошибкам, чем

Employee anEmployee = new Employee();
anEmployee.setName("xxx");
...
list.add(anEmployee);

Так довольно интересно. Добавление идеи в сумку с инструментами ...

Да, я думаю, что это хорошая идея.

Если бы я мог добавить что-нибудь, как насчет этой проблемы:

class People
{
    private String name;
    public People setName(String name)
    {
        this.name = name;
        return this;
    }
}

class Friend extends People
{
    private String nickName;
    public Friend setNickName(String nickName)
    {
        this.nickName = nickName;
        return this;
    }
}

Это будет работать:

new Friend().setNickName("Bart").setName("Barthelemy");

Это не будет принято Eclipse! :

new Friend().setName("Barthelemy").setNickName("Bart");

Это потому, что setName () возвращает People, а не Friend, и PeoplesetNickName отсутствует.

Как мы могли бы написать сеттеры, чтобы они возвращали класс SELF вместо имени класса?

Что-то вроде этого было бы хорошо (если бы существовало ключевое слово SELF). Это все равно существует?

class People
{
    private String name;
    public SELF setName(String name)
    {
        this.name = name;
        return this;
    }
}

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

Из заявления

list.add(new Employee().setName("Jack Sparrow").setId(1).setFoo("bacon!"));

я вижу две вещи

1) Бессмысленное утверждение. 2) Недостаток читабельности.

Это может быть менее читабельным

list.add(new Employee().setName("Jack Sparrow").setId(1).setFoo("bacon!")); 

или это

list.add(new Employee()
          .setName("Jack Sparrow")
          .setId(1)
          .setFoo("bacon!")); 

Это более читабельно, чем:

Employee employee = new Employee();
employee.setName("Jack Sparrow")
employee.setId(1)
employee.setFoo("bacon!")); 
list.add(employee); 

Я делал свои сеттеры довольно давно, и единственная реальная проблема заключается в библиотеках, которые придерживаются строгих getPropertyDescriptors, чтобы получить средства доступа к bean-компонентам для чтения / записи bean-компонентов. В этих случаях у вашего Java-бина не будет авторов, которых вы ожидаете.

Например, я не проверял это наверняка, но я не удивлюсь, что Джексон не распознает их как сеттеры при создании ваших java-объектов из json / maps. Надеюсь, я ошибаюсь в этом (скоро опробую).

На самом деле, я разрабатываю облегченную ORM, ориентированную на SQL, и мне нужно добавить некоторый код за getPropertyDescriptors для распознанных сеттеров, который возвращает это.

Давно отвечу, но мои два цента ... Хорошо. Я бы хотел, чтобы этот свободный интерфейс использовался чаще.

Повторение переменной 'factory' не добавляет дополнительной информации ниже:

ProxyFactory factory = new ProxyFactory();
factory.setSuperclass(Foo.class);
factory.setFilter(new MethodFilter() { ...

Это чище, имхо:

ProxyFactory factory = new ProxyFactory()
.setSuperclass(Properties.class);
.setFilter(new MethodFilter() { ...

Конечно, как уже упоминалось в одном из ответов, для некоторых ситуаций, таких как наследование и инструменты, придется настроить API Java, чтобы сделать это правильно.

Лучше использовать другие языковые конструкции, если они доступны. Например, в Котлин, вы бы использовать с , применить , или пусть . Если использовать этот подход, вам не нужно возвращать экземпляр из вашего установщика.

Такой подход позволяет вашему клиентскому коду быть:

• Безразличен к типу возврата
• Проще поддерживать
• Избегайте побочных эффектов компилятора

Вот несколько примеров.

val employee = Employee().apply {
   name = "Jack Sparrow"
   id = 1
   foo = "bacon"
}


val employee = Employee()
with(employee) {
   name = "Jack Sparrow"
   id = 1
   foo = "bacon"
}


val employee = Employee()
employee.let {
   it.name = "Jack Sparrow"
   it.id = 1
   it.foo = "bacon"
}

Если я пишу API, я использую «return this» для установки значений, которые будут установлены только один раз. Если у меня есть какие-либо другие значения, которые пользователь должен изменить, я использую вместо этого стандартный установщик пустот.

Тем не менее, это действительно вопрос предпочтений, и сеттеры, на мой взгляд, выглядят довольно круто.

Я согласен со всеми авторами, утверждающими, что это нарушает спецификацию JavaBeans. Есть причины сохранить это, но я также чувствую, что использование этого паттерна строителя (на которое ссылались) имеет свое место; пока это не используется везде, это должно быть приемлемо. «Это место», для меня, где конечной точкой является вызов метода «build ()».

Конечно, есть и другие способы установки всех этих вещей, но преимущество в том, что они избегают 1) многопараметрических открытых конструкторов и 2) частично определенных объектов. Здесь у вас есть сборщик, который собирает то, что нужно, и затем вызывает его «build ()» в конце, что может гарантировать, что частично указанный объект не будет создан, так как этой операции может быть предоставлена ​​менее публичная видимость. Альтернативой могут быть «объекты параметров», но это ИМХО просто отодвигает проблему на один уровень назад.

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

Короче говоря, я думаю, что это хорошая практика, если ее правильно использовать.

Плохая привычка: сеттер установил геттер

как насчет явного объявления метода, который делает это для U

setPropertyFromParams(array $hashParamList) { ... }