5

多くの人がこの記事を知っています:ゲッターとセッターの詳細。ゲッター/セッターの邪悪な側面を描写するという説得力のある仕事をしていると思います。また、既存のプロジェクト(未完成)をゲッター/セッターなしのコードに変換してテストしました。機能した。コードの可読性が大幅に向上し、コードが減り、最初は本当に必要だと思っていたゲッター/セッターを取り除くことができました。1か所を除いて。

モデルをビュー部分に配置することは、このアプローチがポイントを逃していると私が思うところです。この記事では、作成者はビルダーを使用してモデルをエクスポートします。問題は、ゲッターで得られるものと同じくらい多くの制御がビルダーに入れられることです。はい、モデルでの表現方法である実装を非表示にします。しかし、ゲッターは、そこに入れられたものとは非常に異なる何かをモデルから抜け出すことはありません。コンストラクターを介して「5」を渡すMoneyオブジェクトを作成する場合、money.getAmount()は、これを他の通貨に変換したり、1つの要素「5」を含む配列として返したりしません。

あなたが設定したものが得られます。そして、ビューを介して値を設定し、最初に設定したものを保持することになっているオブジェクトから値を要求(取得)するときに期待する値を設定します。これらをエクスポートするビルダーは、同じことを期待しています。

これは質問には少し長いです。しかし、私は自分の見解に挑戦したいと思います。ゲッターとセッターは、モデルデータをビューレイヤーに転送するのに悪ですか?

ゲッター/セッターはまったく悪ではないと考える人はたくさんいます。私が言及した以外の場所では彼らは悪であると思うので、これも私が擁護したいと思っていることではありません。

4

2 に答える 2

3

非常に単純なケースでは、データ オブジェクトにはカプセル化する動作がないため、動作のカプセル化の改善に基づく議論は実際には当てはまりません。

私が作成したほとんどのビューは、イベント駆動型です。イベント ドリブン ビューでは、「モデル」を渡して各属性の値を取得し、状態が変化した場合に更新するのではなく、モデルの変更イベントに登録し、モデルが変更されたときにビューを更新します。イベント メカニズムによりモデルがその状態をビューにプッシュできる場合、ビューは状態をプルするためにゲッターを必要としません (また、モデルがリスナーでもある場合はビルダーは必要ありません)。何千もの属性を持つモデルで 1 つの属性のみを変更する場合、ビルダーと新しいモデルをビューに渡すことはどの程度うまく機能するでしょうか?

モデルをデータの塊として考えるのではなく、ビルダー/永続層からリスナー/ビューへの状態通知イベントの転送にキャッシュを実装するものと考えると、モデルがどのように動作するかを簡単に確認できます。これは、ポーリングできる純粋な状態ではなく、カプセル化できます。

于 2009-08-20T18:52:27.870 に答える
1

Scala 言語で使用される代替モデルがありますが、実際にはどこでも使用できます。コンストラクター/エクストラクター モデルです。コンストラクターは、クラスのコンストラクターです。エクストラクタは、呼び出されたときにコンストラクタに渡されたパラメータを返し、このオブジェクトのクローンを作成するメソッドです。

動的言語の場合は、リストを返すだけで完了です。静的に型付けされた言語の場合、オブジェクトのリストを使用して、各型を正しく割り当てることができるように処理するか、型をパラメーター化したタプル クラスを用意して、各パラメーターを正しいタイプ。

Scala の特定のケースでは、Extractor は Java の静的メソッドに似ており、オブジェクトを入力として受け取ります。パラメータを返すか、NoneJava の に似た機能を実行する を返しますnull

アイデアは、作成したものを分解できるということです。これは、ビューが必要とするものとほぼ同じです。

さて、あなたが持っているかもしれない別の概念は、「言うな、聞くな」は、それが適用されるデータでビジネスルールを維持することを意図しているということです。現在、ビューのビジネス ルールは必然的にビューに属しているため、モデルにデータを要求しなければならないという問題が残ります... ゲームを逆転させない場合。モデルは、データを表示するようにビューに指示し、関連するフィールドを要求される代わりにビューに渡す場合があります。したがって、モデルはビューにデータを表示するように指示し、ビューはモデルにデータを更新するように指示します。

于 2009-08-20T19:07:48.710 に答える