0

パスファインディングの例を紹介します。パスを見つけたいときは、最終目的地、初期位置を選択して2つの間の最速の道を見つけるか、最初の位置を定義して、アルゴリズムに終了できるすべてのパスを表示させることができます。テストのためにこれをモックして、最終目的地を言って、そこに「テレポート」すると仮定します。機能が同じであることは明らかです：パスを見つけること。ただし、引数は実装によって異なる場合があります。私はたくさん検索し、たくさんの解決策を見つけました：インターフェースを取り除く、実装のフィールドとしてすべての引数を置く、ビジターパターンを使用する...

しかし、すべての可能な引数（状態ではない）を1つのオブジェクト（MovePreferencesと呼びましょう）に入れ、すべての実装に必要なものを取り入れさせることの欠点は何ですか？確かに、予期しない引数を取る別の実装が必要な場合は、MovePreferencesを変更する必要がありますが、メソッドを追加するだけで、既存のメソッドをリファクタリングしないので、それほど悪くはありません。このMovePreferencesは私のドメインのオブジェクトではありませんが、それでもやりたくなります。どう思いますか？

（この問題に対するより良い解決策がある場合は、自由に回答に追加してください。）

4

2 に答える 2

1

あなたが尋ねている質問は、実際にはなぜインターフェイスがあるのか​​ということです。それに対する答えは非常に簡単だと思います。共有グローバル状態を使用したプログラミングは、プログラマーであるあなたにとっては簡単ですが、さまざまな機能を結合したり、さまざまな顧客のために、レンダリングの機能強化などを行う必要があると、他のすべての人にとってはすぐに渦になります.

スペクトルの対極にあるのは DbC の議論です。すべてのインターフェイスは、交換される知識を最小限に抑えるだけでなく、混乱の可能性を最小限に抑える、非常に制約のあるコントラクトでなければなりません。

率直に言って、これが依存性注入がすぐに混乱に陥る理由の 1 つです。このような設計上の問題が発生するとすぐに、人々はより多くの「オブジェクト」を注入し始めます。多くの場合、1 つのプロパティだけにアクセスするためです。現在の運用の範囲と同じであること。【違う種類の悪夢。】

残念ながら、あなたの質問にはほとんど情報がありません。ルートの概念を正しくモデル化できると思いますか? もちろん。それはそれほど難しいことではありません。ここにいくつかのアイデアがあります：

始点と終点を持つ Route というクラスを作成します。次に、トラバーサルのコレクション。ここでの考え方は、誰かがポイント a からポイント b に到達した方法の概念を Route が完全に無視できるということです。ここでのトラバーサルには、道路、交通、閉鎖などに関する情報が含まれる可能性があります。次に、モックされたケースには、トラバーサルが含まれていない可能性があります。

もう 1 つのオプションは、Route をCompositeにして、各トリップがさまざまなセグメントをつなぎ合わせたものとして表示されるようにすることです。ルートは通常このように表示されます: 2 South を 2 マイル進み、出口を出て、Santa Monica Boulevard を東に 3 マイル進む、などです。このシナリオでは、子を持たないルートのみを作成できます。

最後に、おそらく作成パターンが必要になります。おそらくビルダー。これにより、モック ビルダーを作成して、必要なものから構成されるルートを構築させることができるため、モックの作成も簡素化されます。

Composite と Builder を組み合わせることのもう 1 つの利点は、問題のあるサブセグメントのみを改善しようとすることで、既存のルートから新しいルートを構築できるビルダーを作成できることです。その 1 つのセグメントとその新しいルートを提示します。

于 2012-10-29T19:11:53.780 に答える
0

例を考えてみましょう。

5つの引数がオブジェクトにカプセル化され、3つのメソッドに渡される場合を言います。

オブジェクトの構造が変更された場合は、3つのメソッドすべてに対してテストケースを実行する必要があります。代わりに、メソッドが必要な引数のみを受け入れる場合は、それらをテストする必要はありません。

これから私が見る唯一の問題は、テスト作業の増加です

次に、メソッドが実際に必要とするよりも多くの引数を渡すと、当然、単一責任原則（SRP）に違反します。

于 2012-10-30T08:32:45.227 に答える