Лучше иметь 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)нарушает принцип наименьшего удивления , также известный как показатель WTFs в минуту (из «Чистого кода», изображение ниже), что затрудняет работу новых членов команды (или текущих, через некоторое время вдали от кода) до они понимают, что звонок фактически используется для получения баланса. Подумайте, как отреагируют другие читатели:

Кроме того, сигнатура 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()имеет смысл разделить методы для ясности и для простого добавления поведения, относящегося к ненулевым зарядам .