2

私は、この議論がここ SO で十分にカバーされていることを知っています。

エンティティ/ビジネス オブジェクトの依存関係を解決するために IC コンテナーを使用しないのはなぜですか?

他の質問でも。しかし疑問が残ります。

原則に焦点を当てた質問を維持するために、エンティティビジネス オブジェクトではなく、データを収集する表現タイプを使用しました。

したがって、このようなプリミティブ データに依存するこのような型がある場合(または、より多くのフィールドを使用することもできます):

public class Animal {
  private readonly string name;
  private readonly string nickname;
  private readonly int weight;
  private readonly int heightAtWithers:
  private readonly Color mainColor;
  private raadonly bool isMale;
  private readonly bool isAggressive;

  public Animal(string name, string nickname, int weight,
                int heightAtWithers, Color mainColor,
                bool is Male, bool isAggressive)
  {
    // remainder omitted
  }

  public string Name { get { return this.name; } }

  // remainder omitted
}

これはコンストラクターの過剰注入の場合ですか?

Mark Seemannの本では、依存関係の数を 2 から 4 に抑えるように提案されています (私が間違っていなければ)。

この種のタイプでは、このアンチパターンが適用されない可能性はありますか?

4

2 に答える 2