Скільки логіки в Getters

Мої колеги говорять мені, що в геттерах і сетерах має бути якомога менше логіки.

Але я переконаний, що в геттерах і сетерах може бути приховано багато речей, щоб захистити користувачів / програмістів від деталей реалізації.

Приклад того, що я роблю:

public List<Stuff> getStuff()
{
   if (stuff == null || cacheInvalid())
   {
       stuff = getStuffFromDatabase();
   }
   return stuff;
}

Приклад того, як робота пропонує мені робити речі (вони цитують «Чистий код» від дядька Боба):

public List<Stuff> getStuff()
{
    return stuff;
}

public void loadStuff()
{
    stuff = getStuffFromDatabase();
}

Наскільки логіка доречна у сеттера / геттера? Яке використання порожніх геттерів та сетерів, крім порушення прихованих даних?

Те, як робота каже вам робити речі, кульгавий.

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

У будь-якому випадку спосіб роботи спонукає вас робити речі - кульгавий, оскільки getStuff () вибухне, якщо loadStuff () не буде викликано заздалегідь, тому вони, по суті, хочуть, щоб ви ускладнили свій інтерфейс, ввівши складність порядку операцій. йому. Замовлення операцій в значній мірі стосується найгіршого виду складності, про який я можу придумати.

Логіка в геттерах ідеально чудова.

Але отримання даних із бази даних - це набагато більше, ніж «логіка». Він передбачає низку дуже дорогих операцій, коли багато речей можуть піти не так, і недетермінованим способом. Я б вагався зробити це неявно у геттера.

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

Я думаю, що згідно з "Чистим кодексом" його слід максимально розділити на щось на зразок:

public List<Stuff> getStuff() {
   if (hasStuff()) {
       return stuff;
   }
   loadStuff();
   return stuff;
}

private boolean hasStuff() {
    if (stuff == null) {
       return false;
    }
    if (cacheInvalid()) {
       return false;        
    }
    return true;
} 

private void loadStuff() {
    stuff = getStuffFromDatabase();
}

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

public List<Stuff> getStuff() {
   if (stuff == null || cacheInvalid()) {
       stuff = getStuffFromDatabase();
   }
   return stuff;
}

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

Вони кажуть мені, що в геттерів та сеттерів повинно бути якомога менше логіки.

Потрібно стільки логіки, скільки необхідно для задоволення потреб класу. Мої особисті переваги - якнайменше, але, зберігаючи код, зазвичай потрібно залишити оригінальний інтерфейс із існуючими геттерами / сеттерами, але вкладати в них багато логіки, щоб виправити новішу бізнес-логіку (як приклад, "клієнти" "геттер у середовищі після 911 повинен відповідати" знати свого замовника "та нормам OFAC у поєднанні з політикою компанії, що забороняє появу клієнтів з певних країн [таких, як Куба чи Іран]).

У вашому прикладі я віддаю перевагу вашому і не люблю зразок "дядько боб", оскільки версія "дядько боб" вимагає від користувачів / обслуговуючого персоналу пам’ятати про те, щоб зателефонувати, loadStuff()перш ніж вони дзвонять getStuff()- це рецепт катастрофи, якщо хтось із ваших технічних працівників забуде (або гірше, ніколи не знав). Більшість місць, де я працював за останнє десятиліття, досі використовують код, якому більше десяти років, тому простота технічного обслуговування є важливим фактором.

Ви маєте рацію, ваші колеги помиляються.

Забудьте всі правила про те, що метод отримання або не повинен робити. Клас повинен представляти абстрагування чогось. Ваш клас читається stuff. У Java звичайно використовувати методи 'get' для читання властивостей. Мільярди рядків фреймворків були написані в очікуванні прочитати stuffзателефонувавши getStuff. Якщо ви назвали свою функцію fetchStuffчи щось інше getStuff, то ваш клас буде несумісний із усіма цими рамками.

Ви можете вказати їх на сплячку, де 'getStuff ()' може робити дуже складні речі та викидає RuntimeException при відмові.

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

List<String> names = clientRoster.getNames();
List<String> emails = clientRoster.getEmails();

На відміну від:

myObject.load();
List<String> names = clientRoster.getNames();
List<String> emails = clientRoster.getEmails();

Або ще гірше:

myObject.loadNames();
List<String> names = clientRoster.getNames();
myOjbect.loadEmails();
List<String> emails = clientRoster.getEmails();

Що, як правило, робить інший код набагато вигіднішим і важче читати, тому що вам доведеться почати перебирати всі подібні дзвінки. Крім того, виклик функцій завантажувача або подібного порушує всю мету навіть використання OOP в тому, що ви більше не віддаляєтеся від деталей реалізації об'єкта, з яким працюєте. Якщо у вас є clientRosterоб'єкт, вам не слід дбати про те, як getNamesпрацює, як ви, якщо ви повинні викликати a loadNames, ви просто повинні знати, що getNamesдає вам List<String>імена клієнтів.

Таким чином, звучить, що проблема стосується семантики та найкращої назви функції отримання даних. Якщо компанія (та інші) мають проблеми з префіксом getта setпрефіксом, то як щодо виклику функції щось на зразок retrieveNames? Він говорить про те, що відбувається, але не означає, що операція була б миттєвою, як можна було очікувати від getметоду.

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

Виклик геттера повинен проявляти таку ж поведінку, що і читання поля:

• Вилучення вартості має бути дешевим
• Якщо встановити значення разом із сеттером, а потім прочитати його за допомогою геттера, значення має бути однаковим
• Отримання значення не повинно мати побічних ефектів
• Це не повинно кидати винятку

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

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

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

Коли саме відбувається ініціалізація, може бути, а може і не важливо.

Наприклад, це може бути дуже повільним, і це потрібно робити під час кроку завантаження, коли користувач очікує затримки, а не продуктивність, несподівано ікаючи, коли користувач вперше запускає доступ (наприклад, клацання правою кнопкою користувача, з'являється контекстне меню, користувач вже правою кнопкою миші знову).

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

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

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

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

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

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

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

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

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

   2. Якщо добре пропустити перевірку кешу або дуже важливо, щоб ви гарантували продуктивність O (1) у геттері, тоді використовуйте окремі дзвінки.

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

На мою думку, Геттерс не повинен мати в них багато логіки. Вони не повинні мати побічних ефектів, і ви ніколи не повинні отримувати з них виняток. Якщо звичайно, ви знаєте, що робите. Більшість моїх жителів не мають в них логіки і просто йдуть у поле. Але помітний виняток із цього був публічний API, який повинен бути максимально простим у використанні. Тож у мене був один геттер, який вийшов би з ладу, якби не викликали іншого. Рішення? Рядок коду, як var throwaway=MyGetter;у getter, який залежав від нього. Я не пишаюся цим, але все ще не бачу більш чіткого способу зробити це

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

Можливо, буде доречно використовувати ім'я getCachedStuff()для геттера, оскільки воно не матиме послідовного часу виконання.

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

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

щось на зразок:

public List<Stuff> getStuff()
{
    return Collections.unmodifiableList(stuff);
}

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

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

interface StuffGetter {
     public List<Stuff> getStuff();
}

class StuffComputer implements StuffGetter {
     public List<Stuff> getStuff() {
         getStuffFromDatabase()
     }
}

class StuffCacher implements StuffGetter {
     private stuffComputer; // DI this
     private Cache<List<Stuff>> cache = new Cache<>();

     public List<Stuff> getStuff() {
         if cache.hasStuff() {
             return cache.getStuff();
         }

         List<Stuffs> stuffs = stuffComputer.getStuff();
         cache.store(stuffs);
         return stuffs;
     }
}

Цей дизайн дозволяє легко додавати кешування, видаляти кешування, змінювати основні логіки виведення (наприклад, доступ до БД проти повернення макетних даних) і т. Д. Це трохи зрозуміло, але варто для досить просунутих проектів.

IMHO дуже просто, якщо ви використовуєте дизайн за контрактом. Вирішіть, що повинен надати ваш отримувач, і просто кодуйте відповідно (простий код або якась складна логіка, яка десь може бути залучена або делегована).