通常、ゲッターは常に変数の値を返します。私は自分の文献で、フィールドへのアクセスはゲッターとセッターによって制御されていることを学びました。プログラマーにコードを評価してもらうと、ゲッターとセッターはオブジェクト指向の考え方に違反していると突然言われました。
これまで、オブジェクトに変更を加えたクラスのメソッドで常に出力ステートメントを設定してきました。ただし、出力の作成方法を変更したい場合(たとえば、グラフィカルまたは端末で)、すべてのクラスを書き直す必要があります。したがって、私は次のことを行うことを検討しました。出力はクラスで実現されなくなりましたが、クラスは表示される値を提供するメソッドを提供します。次に、表示用に別のクラスが作成されます。このクラスは、特別なゲッターを使用してオブジェクトの状態を照会し、必要に応じてデータを表示します。ゲッターはこのデータを持つクラスにあります。たとえば、「人間」オブジェクトを作成できます。人間には、とりわけ変数lifeCurrentとlifeMaxがあります。これらの値を関連して設定した場合、これらのフィールドは正常性を表します。 「表示」と呼ばれる別のクラスが、人間の現在の健康状態を表示する役割を果たします。したがって、lifeCurrentとlifeMaxのリストを返すHuman-Classにゲッター「getHealth」を作成します。 Displayクラスには、health(Human)という関数があります。この関数は、Humanからgetterを呼び出し、プログラムのユーザーの値を表示します。このようなゲッターを使用するのは受け入れられるスタイルですか?
あなたがプログラムエンティティに付ける名前はあなたがそれらについてどう思うかを示しています、そしてそれはまっすぐではないようです(私があなたの説明を正しく理解しているなら):
Human
のインスタンスは人間を表しており、それは良いことです。lifeCurrent
とlifeMax
のリストを返すメソッドgetHealth()
は、 "health" islifeCurrent
とlifeMax
。それは奇妙です。私にとって、ヘルスは数値lifeCurrent
とlifeMax
から計算できます(それがモデルの世界の仮定である場合)。したがって、getHealth()
はその計算を実行し、結果を返す必要があります。 [誰かに「車をくれ」と言ったら、指示なしにキットを手に入れたくはありません。最終製品が欲しいのです]。Human
(ビジネスロジック)とDisplay
(ユーザーインターフェイス)で行うように、ビジネスロジックとユーザーインターフェイスを分離することをお勧めします。Display
のクラス名は私を混乱させます。クラス名は名詞でなければならないので、たとえば、あなたが意図したものではないTFTディスプレイ。より適切な名前はPresenter
です。また、Presenter
のさまざまなインスタンスは、さまざまなメディアまたはさまざまな形式で結果を表示する場合があります。health(Human)
のメソッド名が不特定です。それは健康について何をしますか? printHealth
の方が適切な名前です。そして、printHealth()
メソッドがHuman
の代わりにヘルスパラメーター(数値)を受け入れることを期待します。 Human
を受け入れる印刷メソッドがそのHuman
に関するすべての情報を印刷することを期待します。短い答えはnoです。反対側にその情報を保持することのみを目的として、任意の形式でインスタンス変数を返すメソッドを定義するとすぐに、アプリケーション全体に責任がまき散らされ、カプセル化やその他のあらゆる種類の違反が発生します。
質問は次のようになります。これらすべての悪いものを招待する理由がありますかはいの場合、ゲッターも必要な理由があるかもしれません。
理由の1つは、(ビジネスドメインの)自然な境界があり、反対側で何が起こっているのかわからない(できない!)ことである可能性があります。したがって、他の開発者によってどのように表示されるかがわからない場合は、すべてのデータを公開する必要があります。 doがどのように表示されるかを知っている場合、その表示(その抽象的な部分)はオブジェクトに属します(ゲッターを回避するため)。
だから問題は、なぜあなたは出力方法を変えたいのですか?いつでも変更できるようにすることが本当に必要ですか?それとも、一度だけ変更され、おそらく二度と変更されないのでしょうか?