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

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

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

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

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

Подводя итог:

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

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

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

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

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

  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!"));

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

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

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

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

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

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

Это еще лучше:

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

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

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

Это совсем не плохая практика. Но это не совместимо с 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();

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

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

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

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

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

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

Я предпочитал этот подход, но я решил не принимать его.

Причины:

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

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

Это, как всегда, вопрос вкуса. Мне просто нравится подход "наименьших неожиданностей".

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

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

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;
    }
}

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

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

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

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

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() возвращает "Люди", а не "Друг", и нет "PeoplesetNickName".

Как мы можем написать сеттеры для возврата класса SELF вместо имени класса?

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

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

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

На первый взгляд: "Грязно!".

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

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

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

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

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

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

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

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

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

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"
}

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

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

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

Это чище, imho:

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

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

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

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

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

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

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); 

Из утверждения

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

Я вижу две вещи

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

Плохая привычка: набор сеттеров getter get

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

setPropertyFromParams(array $hashParamList) { ... }