のは、私が<strong>PetManager</strong>と<strong>猫</strong>持っていると言う依存

Question

からの依存関係を取得します。私のペットマネージャーから？

class Cat 
{ 
    Cat(PetManager manager, string name, int levelOfStupidity) 
    { 
     this.manager = manager; 
     this.name = name; 
     this.levelOfStupidity = levelOfStupidity; 
    } 

    IWashingService WashingService 
    { 
     get { return this.manager.WashingService; } 
    } 
} 

私は強く、私はそれが依存推測

Answer 1

前述のように、Catは具体的なクラスであるため、意味を問わずすべて公開することができます。コンストラクタの引数を読み取り専用のプロパティとして公開することは、完璧に分かりやすいことです。

しかし、もしCatがICatを実装していたのであれば、PetManagerのような依存関係をICatで公開すると漏洩抽象となることが強く疑われます。

本質的には、interfaces serve as a sort of access modifierです。依存関係を具体的なクラスに公開するのは意味がありますが、インタフェースには関係しません。依存関係はコンストラクタを介して注入されるので、インタフェースの一部になることはありません。コンストラクタの署名は自由度です。

Answer 2

...はい、それは可能だろうと思います。多くの場合、SomethingManagerクラスを持っていることが分かったときには、ロジックをコンポーネントの依存関係に分割するのではなく、1つのクラスにグループ化するだけです。あなたの状況では、あなたは本当にPetManagerクラスを持つべきではなく、代わりにWashingServiceとBusinessLayerオブジェクトの依存関係を直接注入しているようです。

Answer 3

あなたがコントロール/依存性注入スタイルの逆転に加入している場合（あなたのように思われる）、トレードオフについて考える必要があります。

私は、ダイハードがあなたにがあると言うかもしれないと思います。これにはいくつかのメンテナンス上の問題があります。彼らは確かに、たくさんのパラメータを持っていることについては、あまり気にしていません。たとえば、10種類のペットにPetManagerを使用し、10人のペットのうち1人がPetManagerの変更を引き起こす特別な機能が必要だった場合、はPetManagerに依存する他の9つのクラスに影響を与える可能性があります依存関係を個別に注入する方が良いでしょう。

実践しています...あなたは、関連する依存関係の束を別のクラスに抽象化し、それをグループ化の方法として渡し、おそらくオブジェクト構築を単純化します。私はそれで大丈夫です。私はそれに似ています。

全開示：私は他の人々と同じようにこのことについて頑張っているわけではありません。私は異端者かもしれませんが、より少ないパラメーターが見えて、私にとってはよりきれいなにおいがします。私は5年後にもう一度私に尋ねると、私は違った感情を感じるかもしれないという忍耐力がありますが、それは今のところです。

Answer 4

猫が具体的なPetmanagerに依存していると思います.PetManagerをサービスとして抽象化すればは洗濯サービスを提供することができます。