問題タブ [tell-dont-ask]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
6 に答える
3002 参照

oop - 情報の専門家であり、単一責任の原則と対立しないでください。

情報-エキスパートTell-Do n't-Ask、およびSRPは、多くの場合、ベストプラクティスとして一緒に言及されます。しかし、私は彼らが対立していると思います。これが私が話していることです。

SRPを支持するが、Tell-Do n't-Ask&Info-Expertに違反するコード:

Tell-Do n't-Ask&Info-Expertを支持するが、SRPに違反するコード:

これらの慣行がどのように平和的に共存できるかについて私に記入してください。

用語の定義、

  • Information Expert:操作に必要なデータを持つオブジェクトは、操作をホストする必要があります。

  • 尋ねないように言う:仕事をするためにオブジェクトにデータを求めないでください。オブジェクトに作業を行うように指示します。

  • 単一責任の原則:各オブジェクトには、狭く定義された責任が必要です。

0 投票する
6 に答える
1457 参照

c# - シンプルなシナリオ、Tell Don't Ask を組み込む方法

Person と Seat を含む基本的なシナリオをモデル化しようとしています。Person には Status プロパティがあります: 座っているか立っているか。座席には、現在座っている人を指定する Seated プロパティがあります。また、Seat は、特定の人のみが座ることができるという点で特別です。座席が誰かを「受け入れる」というのは奇妙に聞こえるかもしれませんが、他の人よりも特定の人を好むと想像してみてください。

Tell, Don't Ask 」に続いて、Person オブジェクトと Seat オブジェクトをどのように設計すれば、Seat が彼を "受け入れ" たときにのみ、Person が Seat に座ることができ、ステータスが座っている状態に変更されるようにする必要があります。私が最初に考えたのは、 Person には次のように SitDown メソッドが必要だということでした。

しかし、これは Person クラスがシートに座る前にシートの状態を検査する必要があり、シートの Seated プロパティを更新する必要があるようです (プロパティ自体を更新するシートの代わりに):

Seat クラスに人を着席させる方が良いようです:

ただし、これにはまだ、Seat が個人のステータスを変更する必要があります。これは、個人のステータスを更新する方法ですか? 個人だけが自分のステータスを変更できるようにする必要がありますか? この単純なシナリオをどのようにモデル化しますか?

0 投票する
3 に答える
952 参照

oop - 「聞かずに教えて」はユーザー入力の検証に適用されますか?

数日前に初めて OOP の原則を知ったばかりだったので、私は何年もの間、「教えて、尋ねるな」という OOP の原則を見落としていたに違いありません。

しかし、コンテキストは、ASP.NET Web フォーム ページからデータ/ビジネス オブジェクトに移動された検証コードについての議論であり、「Validate()」メソッドはなく、それ自体が検証と検証を行う save メソッドだけでした。 (おそらく)例外を発生させました。なぜこれがこのように設計されたのかを尋ねたところ、聞いたことのない OOP の「言うな、聞くな」という原則に導かれたので、一緒に Google を調べたところ、すぐに教えてもらいました。;)

データがユーザーから引き渡され、処理および/または収集されるビジネス層に渡される前に、データをスクラブするべきではありませんか? その逆ではありませんか? これがどのように良いデザインになるのか、私は混乱しています。

「教えて、尋ねるな」というルールは、ターゲット オブジェクトの状態についてターゲット オブジェクトに尋ねてはならないという考えに関連しているように思われます。この原則は対象物。

0 投票する
4 に答える
389 参照

.net - Tell, Don't Ask の良い例

2 つのオブジェクトがあるとします。

現時点では、次のようなものがあります。

テーブルがマップ可能かどうかをチェックしてからマップしますが、null テーブルもチェックする必要があります。

これを行う方が理にかなっていますか?

そうすれば、テーブルはそれ自身の状態とすべてのチェックをチェックし、新しいマップを作成します。

編集:もう少し情報

1 つのマップに多くのテーブルを含めることができるため、次のようなテーブルのコレクションを取得する MapTables メソッドもあります。

これは、map コマンドを Map タイプのままにしておく必要があることを意味しますか。

どう思いますか?

0 投票する
2 に答える
1084 参照

model-view-controller - ゲッターとセッターなしで mvc を使用できますか?

オブジェクトの状態を公開したくないが、(HTML、XML、または JSON などで) 表示する必要がある場合、MVC 環境でそれを行うにはどうすればよいでしょうか。ダムダウンされた不変オブジェクト(必要に応じて「データクラス」)をエクスポートするエクスポートメソッドを持つことは理にかなっていますか?インターフェイスと対話する render メソッドを追加するのはどうですか? この問題に対する他のアプローチはありますか?

0 投票する
4 に答える
546 参照

actionscript-3 - この単純な例で、「聞いてはいけません」と考えるにはどうすればよいでしょうか。

次の簡単なシナリオで、「教えて、聞かないで」の原則 (以下、「原則」) をどのように順守しますか? Tetris ゲームには、次の例に関連する Board、BlockGrid、および Piece クラスがあります。

FallingPiece が BlockGrid の一番下の行に配置されると、それは "fallingPiece" ではなくなります。私は次の原則に違反していないという点で正しいですか?

しかし、それは明らかに原則に違反していると私が考えるこれと本当に違うのでしょうか?

私は、これらのクラスの関係を原則に沿った適切な方法で設計したとは考えていません。それが欠けている場合は、別のデザインについてアドバイスしてください。


編集、提案された解決策:

イベントを介して「コマンドフィードバック」を提案する回答を使用しました。Board は BlockGrid にピースを移動するように指示します。BlockGrid の movePiece メソッドは、結果に応じて MOVED_TO または MOVE_FAILED イベントを送出します。このイベントは、Board がリッスンしてピースの落下が停止したかどうかを判断するために使用できます。このソリューションに関するフィードバックをお寄せください。

0 投票する
2 に答える
622 参照

c# - 質問しないでタスク間で状態を共有することを伝えます

この単純な例では (もちろん、基本は同じですが、私の現実世界の問題はもう少し複雑です)、どうすれば最大限に教えてドント・アスクを強制できますか? 現在の状態では、モックとテストが困難です。

編集:サンプルをさらにDIishに更新

0 投票する
6 に答える
620 参照

java - ゲッターを回避し、UI のハードコーディングを回避するにはどうすればよいですか?

戦士の強さと戦士の武器をフォームに含む、戦士の説明をコンソールに出力したいと思います。This <description> warrior uses a <weapon>例: This strong warrior uses a butter knife.

わかりやすくするために編集:オブジェクトの内部実装を明らかにするゲッターまたはその他のメソッド (toString など) を使用して、オブジェクトにデータを要求せずにこれを実行したいと考えています。また、現在の UI (コンソール) をオブジェクト自体にハードコーディングせずにこれを行いたいと考えています。

ゲッターの回避

UI をハードコーディングすることでゲッターを回避できます。

ハードコーディングされた UI の回避

ゲッターを使用することで、ハード コーディングされた UI を回避できます。

両方を回避することは可能ですか?上記の例ではどうすればよいですか?

注: いくつかの最初の回答に応じて、ゲッターは命名規則に従うメソッドではありませんgetSomeFieldName。したがって、名前getSomeFieldNameをに変更することaMethodThatIsNotPrefixedByGetは解決策ではありません。ゲッターは、オブジェクトからそれを呼び出したスコープにプライベート データを渡すメソッドです。

完全に明確にするために、ここで対処しようとしている問題は、データのカプセル化に関するものです (この質問にタグが付けられているため)。そのデータを知る必要のないオブジェクトにデータを渡すのを防ぎ、UI のハードコーディングを回避するにはどうすればよいですか?

さらに、これらの質問に基づいて 、多くの回答で提案されている方法で toString を使用する必要はないと思います。toString は、デバッグなどのためにオブジェクトのテキスト表現を生成するためのものであり、任意の出力を返すためではなく、特にアプリケーション依存の出力を返すためのものではないようです。

0 投票する
3 に答える
96 参照

oop - 状態にアクセスできないときにオブジェクトをテストするにはどうすればよいですか?

受け取ったパラメータに基づいてオブジェクトを作成するファクトリクラスがあります。パラメータは、作成するオブジェクトを指定する識別子です。その最初のステップは、データアクセス層を使用してオブジェクトの情報を取得することです。その次のステップは、データに対していくつかのクレンジング/変換を行うことです。最後に、必要なオブジェクトを作成して返します。

クレンジング/変換ステップが正常に行われたことを確認したいのですが、返されるオブジェクトは状態を公開しないため、簡単にテストする方法がわかりません。

データアクセス層とデータベース構造は、レガシーコードで動作する必要があるため、変更できません。

オブジェクトが使用された後、システムでさらにテストすることはできますが、それは維持するのが難しい大きなテストにつながります。

オブジェクトの状態を公開したり、責任を別のクラスに入れてテストしたりすることも考えましたが、どちらのオプションも、テスト用にシステムを変更しているようです。

このようなものをテストする他の方法について何か考えはありますか?

0 投票する
2 に答える
468 参照

java - 「教えて、聞かないで」フォロワークラスでユニットテストする方法は?

この問題は例を挙げて最もよく説明されていると思います。

とてもまとまりがあるので、私はこのパターンが好きです。アクションインターフェイスは、それらのサービスとペアになっています。ビジネスロジックは、多くのクラスで乱雑ではありません。サブクラスはアクションにデータを提供するだけであり、忙しくする必要はありません。ここから採用しました(http://jamesladdcode.com/?p=12)。問題は、otherServiceをモックした場合に、「doTheHardBusinessStuffWith(Objectwhatever)」メソッドの動作をテストするための適切なソリューションが見つからなかったことです。モックでは、ビジネスメソッドがどのように呼び出されるかを気にする必要があります。しかし、どうすればこれを行うことができますか。私はmockitoを使用し、すでにArgumentCaptureで試しました。しかし、ArgumentCaptureを悪用しているため、正しく感じられません。

クラスMyService.myBusinessStuffFor(int id)で使用されているパターンに名前があるかどうか(戦略パターンですか)を知りたいですか?しかし、私の主な質問は、OtherServiceのモックでこのコードをテスト可能にする方法です。