Коли виправдані геттери та сетери

Геттерів та сетерів часто критикують як неналежне ОО. З іншого боку, більшість кодів, що я бачив, мають великі геттери та сетери.

Коли виправдані геттери та сетери? Ви намагаєтесь уникати їх використання? Чи загалом вони зловживають?

Якщо ваша улюблена мова має властивості (мої), то такі речі також вважаються геттерами та сетерами для цього питання. Це те саме з точки зору методології ОО. У них просто приємніший синтаксис.

Джерела критики щодо геттера / сетера (деякі з коментарів, щоб покращити видимість):

• http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html
• http://typicalprogrammer.com/?p=23
• http://c2.com/cgi/wiki?AccessorsAreEvil
• http://www.darronschall.com/weblog/2005/03/no-brain-getter-and-setters.cfm
• http://www.adam-bien.com/roller/abien/entry/encapsulation_violation_with_getters_and
• http://www.yegor256.com/2014/09/16/getters-and-setters-are-evil.html

Висловити критику просто: Геттери та сетери дозволяють маніпулювати внутрішнім станом об'єктів ззовні об'єкта. Це порушує інкапсуляцію. Тільки сам об’єкт повинен дбати про свій внутрішній стан.

І приклад Процедурна версія коду.

struct Fridge
{
    int cheese;
}

void go_shopping(Fridge fridge)
{
     fridge.cheese += 5;
}

Версія коду мутатора:

class Fridge
{
     int cheese;

     void set_cheese(int _cheese) { cheese = _cheese; }
     int get_cheese() { return cheese; }
 }

void go_shopping(Fridge fridge)
{
     fridge.set_cheese(fridge.get_cheese() + 5);        
}

Геттери та сетери ускладнили код набагато складніше, не надаючи належної інкапсуляції. Оскільки внутрішній стан доступний для інших об'єктів, ми не отримуємо багато, додаючи ці геттери та сетери.

Питання раніше обговорювалося в "Переповнення стека":

• https://stackoverflow.com/questions/565095/java-are-getters-and-setters-evil
• https://stackoverflow.com/questions/996179

Наявність геттерів та сетерів само по собі не порушує інкапсуляцію. Що означає порушення інкапсуляції, це автоматично додавання геттера та сеттера для кожного члена даних (у кожному полі , в java lingo), не замислюючись про це. Хоча це краще, ніж оприлюднювати всіх учасників даних, це лише невеликий крок.

Сенс інкапсуляції полягає не в тому, що ви не повинні бути в змозі знати або змінити стан об'єкта за межами об'єкта, а в тому, що ви повинні мати розумну політику для цього.

• Деякі учасники даних можуть бути повністю внутрішніми для об'єкта і не повинні мати ні геттерів, ні сетерів.

• Деякі учасники даних мають бути лише для читання, тому їм можуть знадобитися геттери, але не сетери.

• Деякі члени даних, можливо, повинні відповідати один одному. У такому випадку ви б не надавали сетер для кожного, а єдиний метод їх встановлення одночасно, щоб ви могли перевірити значення на узгодженість.

• Деякі учасники даних можуть потребувати лише певного зміни, таких як збільшення або зменшення на певну кількість. У цьому випадку ви б надали increment()та / або decrement()метод, а не сеттер.

• Але інших, можливо, потрібно буде читати і писати, і вони матимуть і геттер, і сеттер.

Розглянемо приклад а class Person. Скажімо, у людини є ім’я, номер соціального страхування та вік. Скажімо, ми не дозволяємо людям ніколи змінювати свої імена чи номери соціального страхування. Однак вік людини слід збільшувати на 1 щороку. У цьому випадку ви б надали конструктор, який ініціалізував би ім'я та SSN до заданих значень і який ініціалізував би вік до 0. Ви також надали метод incrementAge(), який збільшить вік на 1. Ви також надали б загони для всіх трьох. У цьому випадку ніяких сетерів не потрібно.

У цій конструкції ви дозволяєте перевіряти стан об'єкта поза класом, а ви дозволяєте змінювати його поза межами класу. Однак ви не дозволяєте змінювати стан довільно. Існує політика, яка фактично говорить про те, що ім'я та SSN взагалі не можна змінювати, і що вік можна збільшувати за один рік.

Зараз скажімо, у людини теж є зарплата. І люди можуть змінювати роботу за бажанням, а це означає, що їхня зарплата також зміниться. Для моделювання цієї ситуації у нас немає іншого способу, окрім як запропонувати setSalary()метод! Дозволяти змінювати зарплату за бажанням - це цілком розумна політика в цьому випадку.

До речі, в вашому прикладі, я дав би клас і методи, замість і . Тоді у вас все-таки буде інкапсуляція.FridgeputCheese()takeCheese()get_cheese()set_cheese()

public class Fridge {
  private List objects;
  private Date warranty;

  /** How the warranty is stored internally is a detail. */
  public Fridge( Date warranty ) {
    // The Fridge can set its internal warranty, but it is not re-exposed.
    setWarranty( warranty );
  }

  /** Doesn't expose how the fridge knows it is empty. */
  public boolean isEmpty() {
    return getObjects().isEmpty();
  }

  /** When the fridge has no more room... */
  public boolean isFull() {
  }

  /** Answers whether the given object will fit. */
  public boolean canStore( Object o ) {
    boolean result = false;

    // Clients may not ask how much room remains in the fridge.
    if( o instanceof PhysicalObject ) {
      PhysicalObject po = (PhysicalObject)o;

      // How the fridge determines its remaining usable volume is a detail.
      // How a physical object determines whether it fits within a specified
      // volume is also a detail.
      result = po.isEnclosedBy( getUsableVolume() );
    }

     return result;
  }

  /** Doesn't expose how the fridge knows its warranty has expired. */
  public boolean isPastWarranty() {
    return getWarranty().before( new Date() );
  }

  /** Doesn't expose how objects are stored in the fridge. */
  public synchronized void store( Object o ) {
    validateExpiration( o );

    // Can the object fit?
    if( canStore( o ) ) {
      getObjects().add( o );
    }
    else {
      throw FridgeFullException( o );
    }
  }

  /** Doesn't expose how objects are removed from the fridge. */
  public synchronized void remove( Object o ) {
    if( !getObjects().contains( o ) ) {
      throw new ObjectNotFoundException( o );
    }

    getObjects().remove( o );

    validateExpiration( o );
  }

  /** Lazily initialized list, an implementation detail. */
  private synchronized List getObjects() {
    if( this.list == null ) { this.list = new List(); }
    return this.list;
  }

  /** How object expiration is determined is also a detail. */
  private void validateExpiration( Object o ) {
    // Objects can answer whether they have gone past a given
    // expiration date. How each object "knows" it has expired
    // is a detail. The Fridge might use a scanner and
    // items might have embedded RFID chips. It's a detail hidden
    // by proper encapsulation.
    if( o implements Expires && ((Expires)o).expiresBefore( today ) ) {
      throw new ExpiredObjectException( o );
    }
  }

  /** This creates a copy of the warranty for immutability purposes. */
  private void setWarranty( Date warranty ) {
    assert warranty != null;
    this.warranty = new Date( warranty.getTime() )
  }
}

Основна причина отримання та набору ятрів на Java дуже проста:

• В інтерфейсі можна вказати лише методи , а не поля.

Отже, якщо ви хочете дозволити поле проходити через інтерфейс, вам знадобиться читач і метод запису. Традиційно їх називають getX та setX для поля x.

Від http://www.adam-bien.com/roller/abien/entry/encapsulation_violation_with_getters_and

Стиль JavaBean:

connection.setUser("dukie");
connection.setPwd("duke");
connection.initialize();

OO-стиль:

connection.connect("dukie","duke");

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

Ваше питання: коли виправданий геттер / сетер виправданий? Можливо, коли потрібна зміна режиму, або вам потрібно допитати об’єкт для отримання деякої інформації.

myObject.GetStatus();
myObject.SomeCapabilitySwitch = true;

Думаючи про це, коли я вперше почав кодувати в C #, я написав багато коду в стилі Javabeans, проілюстрованому вище. Але коли я набув досвіду роботи з мовою, я почав робити більше налаштування членів у конструкторі та використовував методи, що більше нагадували вищевказаний стиль OO.

Коли виправдані геттери та сетери?

Коли поведінка "отримати" та "встановити" насправді відповідає поведінці у вашій моделі, чого практично ніколи .

Будь-яке інше використання - це лише обман, оскільки поведінка ділової сфери не зрозуміла.

Редагувати

Ця відповідь, можливо, натрапила на легковажний, тому дозвольте мені розширити. Наведені вище відповіді в основному правильні, але зосереджені на парадигмах програмування OO-дизайну, а також на тих, що пропускають загальну картину. З мого досвіду, це приводить людей до думки, що уникати отримання та встановлення є деяким академічним правилом для мов програмування OO (наприклад, люди думають, що заміна геттерів на властивості є великою)

Насправді це наслідок процесу проектування. Вам не потрібно потрапляти в інтерфейси, інкапсуляцію та шаблони, сперечаючись, чи не порушує ці парадигми, і що таке, чи не добре програмування OO. Єдине, що в кінцевому рахунку має значення, це те, що якщо у вашому домені немає нічого такого, що працює так, додаючи їх у вас, ви не моделюєте свій домен.

Реальність полягає в тому, що малоймовірно, що будь-яка система у вашому доменному просторі має геттери та сетери. Ви не можете підійти до чоловіка чи жінки, відповідальних за нарахування заробітної плати, і просто сказати "Встановити цю зарплату на X" або "Отримати мені цю зарплату" . Такої поведінки просто не існує

Якщо ви вводите це у свій код, ви не проектуєте свою систему відповідно до моделі вашого домену. Так, це розбиває інтерфейси та інкапсуляцію, але це не сенс. Справа в тому, що ви моделюєте щось, чого не існує.

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

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

Як правило, геттери та сетери - це погана ідея. Якщо поле логічно не є частиною інтерфейсу, і ви робите це приватним, це добре. Якщо він логічно є частиною інтерфейсу, і ви оприлюднюєте його, це добре. Але якщо ви зробите це приватним, а потім перегорнетесь і знову зробите його ефективно публічним, надаючи геттеру та сетеру, ви повернетесь туди, з чого почали, за винятком того, що ваш код тепер більш багатослівний і неясний.

Очевидно, є винятки. У Java вам може знадобитися використовувати інтерфейси. Стандартна бібліотека Java має зворотні вимоги сумісності, настільки екстремальні, що переважають нормальні показники якості коду. Можливо навіть, що ви насправді маєте справу з легендарним, але рідкісним випадком, коли є хороший шанс, що ви можете пізніше замінити збережене поле на розрахунок на льоту, не інакше порушивши інтерфейс. Але це винятки. Геттери та сетери - це антидіаграма, яка потребує спеціального обґрунтування.

чи поле доступне безпосередньо чи методом, не дуже важливо.

Важливі інваріанти класу (корисні). І щоб їх зберегти, нам іноді потрібно не мати змоги щось змінити ззовні. Напр. якщо у нас є клас Square з роздільною шириною і висотою, зміна одного з них робить його чимось іншим, ніж квадратним. Тому нам потрібен метод changeSide Якби це був прямокутник, ми могли б мати сетери / публічне поле. Але сетертер ніж би перевіряв, чи краще його більший за нуль.

А конкретними мовами (наприклад, java) є причини, чому нам потрібні ці методи (інтерфейси). І ще одна причина методу - сумісність (вихідна і двійкова). Тож простіше їх додати, а потім подумайте, чи вистачить публічного поля.

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

Ви можете змінити внутрішній інтерфейс на будь-який, зберігаючи інтерфейси однаковими. Якщо ваші інтерфейси не відрізняються, код, який ви кодуєте, не зламається. Ви все одно можете змінити внутрішню інформацію за своїм бажанням.

Мій підхід такий -

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

Якщо це структура POD, я залишаю доступні слоти.

На більш абстрактному рівні питання "хто управляє даними", і це залежить від проекту.

Якщо використання геттерів та сеттерів відчуває складність, проблемою може бути мова, а не сама концепція.

Ось код із другого прикладу, написаного в Ruby:

class Fridge
  attr_accessor :cheese
end

def go_shopping fridge
  fridge.cheese += 5
end

Зауважте, це схоже на перший приклад на Java? Коли геттери та сетери ставляться до громадян першого класу, вони не є клопотом використовувати, і додаткова гнучкість може бути часом справжньою користю - наприклад, ми можемо вирішити повернути для нового сиру холодильник за замовчуванням:

class Fridge
  attr_accessor :cheese

  def cheese
    @cheese || 0
  end
end

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

Розглянемо Sizeклас, який інкапсулює ширину та висоту. Я можу усунути задачі за допомогою конструктора, але як це допомагає мені намалювати прямокутник Size? Ширина та висота не є внутрішніми даними класу; вони є спільними даними, які повинні бути доступними споживачам програми "Size".

Об'єкти складаються з поведінки та стану - або атрибутів. Якщо немає відкритого стану, то лише поведінка є публічною.

Без держави, як би ви сортували колекцію предметів? Як би ви шукали конкретний екземпляр об’єкта? Якщо ви використовуєте лише конструктори, що відбувається, коли ваш об’єкт має довгий список атрибутів?

Жоден параметр методу ніколи не повинен використовуватися без перевірки. Тому лінь писати:

setMyField(int myField){
    this.myField = myField;
}

Якщо ви все-таки пишете так, то ви принаймні підготувались до використання сетера для перевірки; це краще, ніж публічне поле - але лише ледве. Але принаймні у вас є послідовний публічний інтерфейс, до якого ви можете повернутися та ввести правила перевірки, не порушуючи код своїх клієнтів.

Геттери, сетери, властивості, мутатори, називайте їх, що вам захочеться, але вони необхідні.

Якщо геттери і сетери порушують інкапсуляцію і справжній ОО, то я серйозно переживаю проблеми.

Я завжди відчував, що предмет представляє все найкраще, що спадає на думку, що вам це потрібно зробити.

Я щойно закінчив писати програму, яка генерує Mazes на Java, і у мене є клас, який представляє "Maze Squares". У мене є дані цього класу, які представляють координати, стіни та булеві і т.д.

У мене повинен бути якийсь спосіб змінити / маніпулювати / отримати доступ до цих даних! Що мені робити без геттерів та сетерів? Java не використовує властивості, а встановлення всіх моїх даних, які є локальними для цього класу, для загальнодоступних - ВИЗНАЧЕНО порушенням інкапсуляції та OO.

По-перше, є в основному два типи об'єктів, які я буду коментувати, значення та типи послуг.

Типи сервісів ніколи не повинні мати сетерів, незалежно від необхідних залежностей. Найкращий спосіб передати залежності - це через конструктор чи завод, завдяки якому всі екземпляри повністю формуються з самого початку, просто та просто.

Типи значень також повинні бути незмінні, з іншого боку, є випадки, коли це не практично, наприклад, ORM або якесь інше відображення, наприклад, від віджета до об'єкта. Усі інші типи значень, які передаються навколо системи з одного шару або частини в інший, повинні бути незмінними і не повинні мати сеттерів.

Геттер / сетер виправданий так само, як і будь-який інший публічний метод. Виправдання в основному тому, що ми хочемо надати інтерфейс із зовнішнім світом, який визначає, як взаємодіє наш клас з іншими класами. Ми робимо це головним чином тому, що хочемо зменшити зв’язок між окремими сутностями. Зменшити з'єднання - це корисна річ з багатьох причин:

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

Так, getters та setters є анти-шаблоном в об'єктно-орієнтованому програмуванні і його ніколи не слід використовувати: http://www.yegor256.com/2014/09/16/getters-and-setters-are-evil.html . У двох словах, вони не вписуються в об'єктно-орієнтовану парадигму, оскільки вони спонукають вас ставитися до об'єкта, як до структури даних. Яка основна помилка.

Я сподіваюся, що все, що розробляється компанією IDE, яка розробляє вашу мову програмування автоматично, не порушує "Принципи орієнтації на об'єкти".

Це, як говорять, будь-коли, коли у вас є публічна змінна діапазон, використовуйте геттер і сеттер, і ви золоті. Мені здається, це необхідний елемент надзвичайно об'єктно-орієнтованого принципу інкапсуляції - навіть якщо це просто схоже на безліч непотрібного коду.

Причиною їх використання є те, що правильна інкапсуляція все-таки може відбутися, і поки ви відтягуєте шар, який дозволяє людині, що маніпулює вашим об'єктом, відчувати ваш об’єкт, ви можете забрати цей об’єкт, не знаючи навіть, що це правильно?

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

Я думав, у нас тут будуть більш звичні відповіді?

Як правило, геттери та сетери є надзвичайно OOP (кожен, хто скаже що-небудь інше, не так, просто).

Хоча вам потрібно пам’ятати, щоб не перевантажувати інженера, ніколи не робіть геттера чи сетера, які не потрібні. Будь-яка інформація, яку ви не збираєтеся використовувати іншим класом, не повинна мати жодного геттера чи сетера.

Хоча причина, чому ви не оприлюднюєте поля та замість цього отримуєте геттери та сетери, здебільшого:

• Неможливо зробити належні тести, використовуючи поля. Геттери / сетери значно кращі в цьому плані.

• Правильно використовувати поля в режимі програмування в режимі реального часу неможливо. Синхронізовані геттери / сетери - це шлях.

• Тема інтерфейсу (вже пояснено, тому я не буду).

• Це легше використовувати при правильному використанні системи.

• Набагато складніше дізнатись, які класи використовує ваш клас, і що зламається, якщо змінити поле, ніж getter / setter.

Тому єдиний раз, коли ви використовуєте загальнодоступне поле замість геттера / сеттера, це коли ви не робите офіційний проект, а натомість просто робите це для розваги і не можете турбуватися з геттером / сеттером.