オブジェクトに無効な状態がある場合、ゲッターは例外をスローする必要がありますか？

一般的なOOPの問題だと思っていても、特にJavaでこの問題によく遭遇します。つまり、例外を発生させると、設計上の問題が明らかになります。

String nameフィールドとフィールドを持つクラスがあるとしString surnameます。

次に、これらのフィールドを使用して個人の完全な名前を作成し、ある種のドキュメント（請求書など）に表示します。

public void String name;
public void String surname;

public String getCompleteName() {return name + " " + surname;}

public void displayCompleteNameOnInvoice() {
    String completeName = getCompleteName();
    //do something with it....
}

次にdisplayCompleteNameOnInvoice、名前が割り当てられる前にが呼び出された場合にエラーをスローして、クラスの動作を強化したいと思います。いい考えですね。

getCompleteNameメソッドに例外発生コードを追加できます。しかし、この方法では、クラスユーザーとの「暗黙の」契約に違反しています。一般に、値が設定されていない場合、ゲッターは例外をスローすることは想定されていません。わかりました。これは単一のフィールドを返さないため、これは標準のゲッターではありませんが、ユーザーの観点からは区別が微妙すぎて考えられない場合があります。

または、の内部から例外をスローできdisplayCompleteNameOnInvoiceます。しかし、そうするためには、直接nameまたはsurnameフィールドをテストする必要がありますgetCompleteName。そうすることで、で表される抽象化に違反することになります。完全な名前を確認して作成するのは、このメソッドの責任です。他のデータに基づいて、場合によっては十分であると判断することさえできsurnameます。

だから、唯一の可能性は、メソッドのセマンティックを変更するようだgetCompleteNameとcomposeCompleteName、それをより「アクティブ」の行動と、例外をスローする能力を示唆しています。

これはより良い設計ソリューションですか？私はいつもシンプルさと正確さの間で最高のバランスを探しています。この問題の設計参照はありますか？

名前を割り当てずにクラスを構築することを許可しないでください。

DeadMGが提供する答えはそれをほとんど否定していますが、少し違う言い方をしましょう：無効な状態のオブジェクトを持つことは避けてください。オブジェクトは、それが果たすタスクのコンテキストで「全体」である必要があります。または、存在しないはずです。

したがって、流動性が必要な場合は、Builderパターンのようなものを使用します。または、「実物」とは対照的に、構築中のオブジェクトの別個の具体化であるもの。後者は有効な状態を持つことが保証され、その状態で定義された操作を実際に公開します（例getCompleteName）。

無効な状態のオブジェクトはありません。

コンストラクターまたはビルダーの目的は、オブジェクトの状態を一貫性のある使いやすいものに設定することです。この保証がないと、オブジェクトの状態が不適切に初期化されると問題が発生します。この問題は、並行性を処理していて、オブジェクトの設定が完了する前に何かがオブジェクトにアクセスできる場合、さらに複雑になります。

したがって、この部分の質問は、「なぜ名前または姓をヌルにすることを許可しているのですか？」です。それが適切に機能するためにクラスで有効なものでない場合は、許可しないでください。オブジェクトの作成を適切に検証するコンストラクターまたはビルダーを用意し、正しくない場合はその時点で問題を提起します。また、存在する@NotNull注釈の 1つを使用して、「これはnullにできない」ことを伝え、コーディングと分析でそれを強制することもできます。

この保証が適切に設定されていると、コードとその動作について推論するのがはるかに簡単になり、奇妙な場所で例外をスローしたり、ゲッター関数を過度にチェックしたりする必要がなくなります。

より多くのことをするゲッター。

このテーマに関しては、かなり多くのことがあります。あなたは持っているどのくらいのゲッターのロジックとゲッターとセッターの内側に許可する必要がありますか？ここから、ゲッターとセッターがスタックオーバーフローで追加のロジックを実行します。これは、クラス設計で何度も発生する問題です。

このコアは次のものから来ています。

一般に、値が設定されていない場合、ゲッターは例外をスローすることになっていません

そしてあなたは正しい。彼らはすべきではありません。彼らは世界の残りの部分に対して「馬鹿げている」ように見え、期待されることをするべきです。そこにあまりにも多くのロジックを入れると、最小限の驚きの法則に違反する問題につながります。それに直面して、ゲッターをラッピングするのは本当に嫌です。try catchなぜなら、一般的にそれをするのがどれだけ好きか知っているからです。

また、JavaBeansフレームワークなどのメソッドを使用する必要がありgetFoo、EL呼び出しから何かを取得してBeanを取得する必要がある場合もあります（そのため、<% bar.foo %>実際にgetFoo()クラスを呼び出します。どちらかが明らかに正しい答えになりうる状況を簡単に思い付くことができるからです）

また、特定のゲッターがインターフェイスで指定されるか、リファクタリングされるクラスの以前に公開されたパブリックAPIの一部であった可能性があることを認識します2つのフィールドに分けます）。

一日の終わりに...

推論するのが最も簡単なことをしてください。このコードの維持に費やす時間は、設計に費やす時間よりも長くなります（ただし、設計に費やす時間は短くなるほど、維持に費やす時間は長くなります）。理想的な選択は、メンテナンスにそれほど時間がかからないように設計することですが、数日間は考えずに座ってはいけません-これが実際に数日後に影響を与える設計の選択でない限り。

ゲッターのセマンティックな純度に固執しようとするとprivate T foo; T getFoo() { return foo; }、ある時点で問題が発生します。コードがそのモデルに適合しない場合や、そのように維持しようとする歪みが意味をなさない場合があり、最終的に設計が困難になります。

設計の理想は、コードで望んでいるようには実現できないことを時々受け入れます。ガイドラインはガイドラインであり、シャックルではありません。

私はJavaの男ではありませんが、これはあなたが提示した両方の制約を順守しているようです。

getCompleteName名前が初期化されていない場合、例外をスローしませんdisplayCompleteNameOnInvoice。

public String getCompleteName()
{
    if (name == null || surname == null)
    {
        return null;
    }
    return name + " " + surname;
}

public void displayCompleteNameOnInvoice() 
{
    String completeName = getCompleteName();
    if (completeName == null)
    {
        //throw an exception.
    }
    //do something with it....
}

誰もあなたの質問に答えていないようです。
人々が信じたいものとは異なり、「無効なオブジェクトを避ける」ことは実際的な解決策ではないことがよくあります。

答えは：

はい、そうすべきです。

簡単な例：FileStream.LengthC＃/。NETではNotSupportedException、ファイルがシーク可能でない場合にスローされます。

あなたは全体の逆さまのチェック名のものを持っています。

getCompleteName()どの機能がそれを利用するかを知る必要はありません。したがって、name呼び出しdisplayCompleteNameOnInvoice()がない場合はgetCompleteName()責任を負いません。

ただし、nameはの明確な前提条件ですdisplayCompleteNameOnInvoice()。したがって、状態をチェックする責任を負う必要があります（または、必要に応じて、チェックの責任を別のメソッドに委任する必要があります）。