問題タブ [tell-dont-ask]

質問

複数のオブジェクトが関係する機能を実行する際に、 「教えて、尋ねるな」の原則を守るにはどうすればよいですか。

例 - レポートの生成

次のオブジェクトがあります（説明のみを目的としています）：

車、馬、うさぎ

これらのオブジェクト間に関係はありませんが、これらのオブジェクトに基づいてレポートを生成したいと考えています:

この方法の問題点は、各オブジェクトからデータを「プル」する必要があることです。これは、「教えて、尋ねるな」という規則に違反しています。各オブジェクトの内部を非表示にして、レポートを生成してもらいたいと思います。

...しかし、3 つの部分的なレポートが表示されます。さらに、必要なすべてのレポート (HTML、JMS、XML、JSON ....) を生成する方法を、Rabbit が知る必要はないと思います。

最後に、レポートの生成中に、複数の項目をオンにしたい場合があります。

実用的なプログラミングの原則を維持しようとして、「Tell, Don't Ask」の原則に基づいてユーザー パスワードの変更を処理する方法を決定しようとしています。

パスワードが 30 日ごとに期限切れになるユーザー オブジェクトがあります。パスワードの有効期限が切れている場合、パスワードの有効期限が切れている/パスワードの変更ビューを表示できるようにする必要があります。パスワードの有効期限が切れているかどうか (状態) をオブジェクトに尋ねてから、表示するビューを選択することは、原則に違反しているように思えます。

この状況を処理する最善の方法は何ですか?

私が取り組んでいる実際の何かの代用として、モデルの構築を検討してください。モデルパーツを表すクラスがあり、Parts指定されたパラメータに基づいてパーツを製造したり、検証したりするためのメソッドが完備されてGlueいます。ほぼ同じことを行うModelBuilderクラスとクラスがあります。

接着剤や部品をカプセル化して製造できます。次に、myPartsInstanceとGlueInstancemyModelBuilderをパラメーターとしてmyに渡します。ここですべてがバラバラになります。PartsModelBuilderにビルドするように指示することはできますが、そのためには、 （およびおそらく）のデータにアクセスする必要がありますGlue。たとえば、PartsInstance.Part[0]適切に構築するために、のコーナーまたは中心がどこにあるかを知る必要があるかもしれません。

私はここで困惑しています。なぜなら、Tell、Do n't Askキャンプは、パーツが何らかの形でそれ自体を構築する必要があると言うように思われるからです。しかし、それは私には意味がありません。一部はモデル全体ではなく一部です。それがそれ自体を構築する必要があります。はModelBuilder非常に複雑である可能性があり、Parts他の場所で使用される可能性があります。一方、私はPartsInstanceオブジェクトの状態を調べて、その状態に基づいて決定を下しています。さらに、決定はPartsとにかく概念の中にのみ適合するものではないかもしれません。Glueそれは私が選んだタイプを含むかもしれません。

カプセル化に違反しないように、この例を作成または作り直すにはどうすればよいですか？

「教えて、聞かないで」が「単一責任」の原則と矛盾しているように見える場合があります。私はこのテーマに関する他の議論を見てきましたが、この状況に最も適切なオブジェクト指向のアプローチをまだ理解することができませんでした。

さまざまなソースからのデータのコレクションを読み取って操作するプログラムがあります。データを保持および操作するためのクラス（「DataSet」クラス）を作成しました。これには、2つのデータセットを比較して違いを含む新しいデータセットを生成したり、データセットをファイルに書き込んだりするなど、データセットに対してさまざまな操作を実行するためのメソッドが含まれています。

データセットに対して分析を実行し、結果をレポートに出力したいと思います。これをコーディングする最初の試みは、データセットに問い合わせてそこから情報を抽出し、レポートを作成しますが、これは「教えて、聞かないでください」という原則に反しているようです。したがって、分析メソッドをDataSetクラス内に配置し、データセットにそれ自体を分析してレポートを生成するように指示する必要がありますか？これは単一責任の原則に違反しますか？将来、他のタイプの分析を実行したい場合はどうなりますか？DataSetクラスによって、そのコア目的とは関係のない多くの異なる分析ルーチンで非常に肥大化する可能性があります。

誰かがここで最良のアプローチを提案できますか？この問題に対処する特定のデザインパターンはありますか？

今日は「教えて！聞かないで！」について考えていました。このコードを試しています。

インターフェース:

実装:

設計原則に準拠することが常に可能であるとは限らないことを私は知っています。しかし、最終的に私はオブジェクトを求めているこのコードに固執しました:

実用的かどうかにかかわらず、それを解決することは可能ですか?

編集 1:
変更してIValidationContext名前を変更した場合:

コンテキストを尋ねる必要はありません:

現在、コンテキストは内部状態に基づいて計算を呼び出す責任があります。...気分が悪い...

編集2：
「教えて！聞かないで！」についての小さな記事を読みました。オブジェクトにその内部状態を尋ねてから、その状態に応じてオブジェクトに何かを伝えることは、「教えてください! 尋ねないでください!」に違反します。しかし、別のオブジェクトに何かを伝えることは問題ありません。これはここに当てはまりますか？

ところで。と の boolean-isvalid-result を導入しValidateInputますValidateOutput。コードを次のように変更できます。

つまりね。シナリオに応じて、動作、外観、テキストが異なるボタンがあります。現時点では、大まかに次のようになります。

両方のボタンに IF statement_B が true である必要がある CSS クラスもあります。

だからめちゃくちゃです。そして、私は最近、私がとても気に入った「教えて、聞かないで」の原則について読んだので、ここでそれを適用したいと思います...しかし、どうすればよいかわかりません.

ヘルパーを作成できることはわかっていますが、理由があるため、それらから離れたいと思います（そうする正当な理由がいくつかありますが、それらはこの質問の範囲を超えています）。最後のリソースとしてこれに頼ることはできますが、別の解決策を見つけたいと思います。

次のような 2 つのクラスがあります。

関連するサブスクリプションがサイトがアクティブかどうかを決定する場合、hostname_active?ルートの制約として、また a) 存在するかどうか、および b) アクティブであるかどうかを決定する必要がある他のクラスでメソッドを使用します。

SOに関する別の質問から取得：

聞かないで伝えるとは、基本的に、オブジェクトの状態についてクエリを実行し、その状態に基づいて決定を下し、同じオブジェクトに何をすべきかを伝えてはならないことを意味します。オブジェクトが必要な情報をすべて持っている場合は、それ自体で決定する必要があります。

私はそうしませんが、私のコードは、サイトとサブスクリプションの間の結合だけでなく、データベースに触れずにテストするのが難しくなる ActiveRecord への結合に関しても、かなり結合されているように感じます。

サイトの状態を判断するために、関連するサブスクリプションに問い合わせるのを避けるには、どのように構成しますか? また、これは「聞くな」の違反だと思いますか?

tellDontAskシナリオを作成するために、アプリケーションのコード変更を通知するためにcSharpでイベントを発生させようとしました。

イベントクラスから実装する単純なクラスがあります

イベントクラスを次のように定義します

Nunitテストでコードを使用しようとしています

テストを実行すると、null参照例外が発生します

System.NullReferenceException：オブジェクト参照がオブジェクトのインスタンスに設定されていません。

私は何かが欠けていると信じていますが、理解できませんでした、何か考えはありますか？

私は2つのクラスを持っていParserますItem. Parser クラスは、構造化されたドキュメントを解析し、 のItemようなものを呼び出すと -objectsを返しますParser::GetItem(int some_id)。Item クラスは、"Tell - don't ask" の原則を念頭に置いて作成されました。Parserつまり、 on 構築によって埋められたいくつかの内部変数の getter メソッドがないということです。

Parser問題は次のとおりです。クラスをユニットテストするにはどうすればよいですか? Item内部変数が正しく解析されたかどうかを確認する方法は? クラスを再編成する必要がありますか? Itemパーサー インターフェイスが完全に構築されたオブジェクトを返すのは設計が悪いのでしょうか?