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

Question

Это хорошая или плохая идея, чтобы сеттеры в 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.

Answer 1

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

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

Answer 2

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

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

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

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

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

Answer 3

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

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

setPropertyFromParams(array $hashParamList) { ... }

Answer 4

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

Повторение переменной '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, чтобы сделать это правильно.

Answer 5

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

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

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

Answer 6

Из выписки

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

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

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

Answer 7

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

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