Краще мати 2 методи з чітким значенням, або просто 1 метод подвійного використання?

Щоб спростити інтерфейс, краще просто не мати getBalance()методу? Перехід 0до charge(float c);волі дасть той самий результат:

public class Client {
    private float bal;
    float getBalance() { return bal; }
    float charge(float c) {
        bal -= c;
        return bal;
    }
}

Можливо, запишіть у javadoc? Або просто залиште це користувачеві класу, щоб зрозуміти, як отримати баланс?

Ви, здається, припускаєте, що складність інтерфейсу вимірюється кількістю елементів, які він має (методи, в даному випадку). Багато хто стверджує, що, якщо пам'ятати, що chargeметод може бути використаний для повернення балансу, Clientдодає набагато більшу складність, ніж наявність додаткового елемента getBalanceметоду. Зробити речі більш явними набагато простіше, особливо до того, що це не залишає двозначності, незалежно від більшої кількості елементів в інтерфейсі.

Крім того, виклик charge(0)порушує принцип найменшого здивування , відомий також як показник WTF за хвилину (з чистого коду, зображення нижче), що ускладнює новим членам команди (або поточним, через деякий час далеко від коду) до вони розуміють, що дзвінок насправді використовується для отримання балансу. Подумайте, як реагували б інші читачі:

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

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

public class Client {
  private float bal;
  float getBalance() { return bal; }
  void charge(float c) { bal -= c; }
}

ІМО, замінивши getBalance()з charge(0)через додаток не є спрощення. Так, це менше рядків, але це затьмарює значення charge()методу, який потенційно може викликати головні болі внизу лінії, коли вам чи комусь іншому потрібно переглянути цей код.

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

Важливо пам’ятати, що ваш код повинен бути самодокументованим. Коли я дзвоню charge(x), я розраховую xстягнути плату. Інформація про баланс є вторинною. Більше того, я, можливо, не знаю, як charge()реалізується, коли я його закликаю, і я точно не знаю, як це реалізується завтра. Наприклад, розгляньте це потенційне майбутнє оновлення для charge():

float charge(float c) {
    lockDownUserAccountUntilChargeClears();
    bal -= c;
    Unlock();
    return bal;
}

Раптом використання charge()балансу не виглядає так добре.

Використання charge(0);для отримання балансу є поганою ідеєю: одного дня хтось може додати там якийсь код для реєстрації зарядів, що проводяться, не усвідомлюючи іншого використання функції, і тоді кожен раз, коли хтось отримає баланс, він буде реєструватися як плата. (Існують способи навколо цього, наприклад, умовне твердження, яке говорить щось на зразок:

if (c > 0) {
    // make and log charge
}
return bal;

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

Коротше кажучи: не покладайтеся ні на своїх користувачів, ні на своїх наступників програмістів, розуміючи, що charge(0);це правильний спосіб отримати баланс, адже, якщо немає документації, яку вони гарантовано не пропустять, відверто кажучи, це виглядає як найстрашніший спосіб отримання балансу. можливо.

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

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

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

(Це модель дизайну, яку я не пригадую конкретної назви: визначення складного інтерфейсу, що викликає виклик, з точки зору мінімально зручного втілення в реалізацію. У Classic Mac OS мінімальний інтерфейс для операцій малювання називався "вузьким місцем" але це, мабуть, не є популярним терміном.)

Якщо це не так (є кілька реалізацій або саме одна), то розділення методів для ясності та дозволення простого додавання поведінки, що стосується ненульових зарядів charge(), має сенс.