Чи погана практика змусити сетера повернути "це"?

Хороша чи погана ідея змусити сетерів у Java повернути "це"?

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. Фабричні / статичні методи (недолік: те саме, що і перевантажені конструктори - стає непростим, коли їх буде більше декількох)

Якщо ви збираєтеся встановити лише декілька властивостей одночасно, я б сказав, що повертати "це" не варто. Це, безумовно, падає, якщо згодом ви вирішите повернути щось інше, наприклад, показник стану / успіху / повідомлення.

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

Зазвичай це називається модель побудови або вільний інтерфейс .

Він також поширений в 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 * повертають запити, неможливо сказати лише підписом, як ним користуватися. Наприклад:

  Query setWhatever(String what);

• Це вносить неоднозначність: чи метод модифікує поточний об'єкт (ваш шаблон) чи, можливо, Запит дійсно незмінний (дуже популярний і цінний шаблон), і метод повертає новий. Це просто ускладнює використання бібліотеки, і багато програмістів не використовують цю функцію. Якби сеттери були сеттерами, було б зрозуміліше, як ним користуватися.

Для цього я вважаю за краще використовувати методи "з":

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

З ланцюжкомXyz () умовами іменування практично всі повинні бути задоволені.

Якщо ви не хочете повертатися '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є a Consumer<MyValue>. Якщо у вас є повернення setter this, то це вже не дійсний екземпляр Consumer<MyValue>, а, скоріше 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.

Ця схема (призначена для каламбура), яка називається «вільний інтерфейс», стає на сьогодні досить популярною. Це прийнятно, але це насправді не моя чашка чаю.

Оскільки він не повертає недійсності, він більше не є дійсним параметром властивостей 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, а не Друга, і немає 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, щоб отримати доступ до пристроїв для читання / запису файлів. У цих випадках у вашого "боба" Java не буде тих письменників, яких ви очікували.

Наприклад, я не перевірив це напевно, але я не здивуюсь, що Джексон не визнає їх сеттерами під час створення вам об’єктів Java з json / maps. Я сподіваюсь, що я помиляюся на цьому (я протестую це незабаром).

Насправді я розробляю полегшений ORM, орієнтований на SQL, і мені потрібно додати деякий код beyong getPropertyDescriptors до визнаних сетерів, які це повертають.

Давно відповідь, але два мої центи ... Це добре. Хочеться, щоб цей вільний інтерфейс використовувався частіше.

Повторення змінної "заводу" не додає більше інформації нижче:

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

Це чистіше, імхо:

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

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

Краще використовувати інші мовні конструкції, якщо вони є. Наприклад, в Котлин, ви б використовувати з , застосувати , або нехай . Якщо ви використовуєте цей підхід, вам дійсно не потрібно буде повертати екземпляр зі свого сетера.

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

• Байдужий до типу повернення
• Простіше в обслуговуванні
• Уникайте побічних ефектів компілятора

Ось кілька прикладів.

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, я використовую "повернути це" для встановлення значень, які будуть встановлені лише один раз. Якщо у мене є якісь інші значення, які користувач повинен мати змогу змінити, я замість цього використовую стандартний сетевий параметр.

Однак, це дійсно питання уподобань, і прив’язка сетерів дійсно виглядає досить круто, на мою думку.

Я погоджуюся з усіма плакатами, які стверджують, що це порушує специфікацію JavaBeans. Є причини, щоб зберегти це, але я також вважаю, що використання цього шаблону для будівельників (на що було сказано) має своє місце; до тих пір, поки він не використовується скрізь, він повинен бути прийнятним. Для мене, це місце, де кінцевою точкою є заклик до методу "build ()".

Звичайно, існують і інші способи налаштування всіх цих речей, але перевага тут полягає в тому, що це дозволяє уникнути 1) багатопараметричних публічних конструкторів та 2) частково заданих об'єктів. Тут ви маєте будівельника зібрати необхідне, а потім в кінці викликати його "build ()", який може переконатися, що частково заданий об'єкт не побудований, оскільки ця операція може отримати меншу публічну видимість. Альтернативою були б "об'єкти параметрів", але IMHO просто відсуває проблему на один рівень.

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

Коротше кажучи, я вважаю, що це правильна практика, якщо її правильно використовувати.

Погана звичка: сетер встановив отримувач отримати

як щодо явного оголошення способу, який робить це для U

setPropertyFromParams(array $hashParamList) { ... }