明確な意味を持つ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ます。物事をより明確にすることは、特にインターフェイス内の要素の数が多いかどうかに関係なく、あいまいさを残さない点で、はるかに簡単です。

さらに、呼び出しは最小驚 as charge(0)の原則に違反します。これは、1分あたりのWTFメトリックとも呼ばれ（クリーンコード、下の画像から）、チームの新しいメンバー（またはコードからしばらく離れた現在のメンバー）が彼らは、コールが実際にバランスをとるために使用されることを理解しています。他の読者がどのように反応するかを考えてください：

また、chargeメソッドのシグネチャは、オブジェクトの状態を変更しながら新しい値を返すため、1つのこととコマンドとクエリの分離を行うというガイドラインに反します。

全体として、この場合の最も単純なインターフェイスは次のようになると思います。

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

IMO、交換する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);がバランスをとる正しい方法であることに気づかないでください。可能。

たくさんの答えがあることは知っていますが、反対するもう1つの理由charge(0)は、単純なタイプミスcharge(9)が原因で、顧客の残高を取得するたびに残高が減少することです。優れた単体テストがあれば、そのリスクを軽減できる可能性がありますが、電話をかけるたびに勤勉にならなければ、chargeこのような事故が起こる可能性があります。

私はそれが特定のケースに言及したいと思います少ない、より多目的、メソッドを持ってしても意味が：ある多型の多くは、多くがあれば実装このインタフェースを、特に、これらの実装が同期して更新できない個別に開発されたコードである場合（インターフェイスはライブラリによって定義されます）。

その場合、各実装を記述する作業を単純化することは、その使用の明確さよりもはるかに価値があります。前者は契約違反のバグを回避するためです（2つの方法は互いに矛盾します）。ヘルパー関数や定義スーパークラスのメソッドによって回収さgetBalanceの面でcharge。

（これはデザインパターンであり、特定の名前は思い出せません：実装者に優しい最小限のインターフェイスという点で、呼び出し元に優しい複雑なインターフェイスを定義します。クラシックMac OSでは、描画操作の最小インターフェイスは「ボトルネック」と呼ばれていましたしかし、これは一般的な用語ではないようです。）

これが当てはまらない場合（実装が少ないか、正確に1つある場合）、明確にするためにメソッドを分離し、ゼロ以外の電荷に関連する動作を単純に追加できるようにすることcharge()は理にかなっています。