2

インターフェイス分離の原則は、コンビニエンス/ヘルパー メソッドにどのように適用されますか? 例えば：

取引先を表すインターフェースを作りたい。最低限必要なのは、パートナーのリスト全体を設定または取得するセッター メソッドとゲッター メソッドです。

Interface Partners {
  method getList();
  method setList();
}

また、特定の人がパートナーのリストに含まれているかどうかを知らせるために、contains() メソッドも必要です。getPartners() を呼び出して、指定された人がそのリストに含まれているかどうかを確認するため、これはヘルパーまたは便利なメソッドと見なします。

インターフェイス分離の原則に関する私の理解では、contains() メソッドを別のインターフェイスに分離する必要があるということです。私の例では大したことではありませんが、ヘルパー メソッドのリストがすぐに長くなる可能性があるため (addPartner、addPartnerByID、addPartnerByUserid など)、これは実際的な問題です。

私の懸念は、contains() メソッドを保持するためのインターフェースの名前を選ぶのが非常に難しいと感じていることです。あなたのデザインに何か問題があります。PartnersSupportingSetInclusionChecks という名前のインターフェイスを使用するのは適切ではないように思われます。また、PartnerHelperMethods という名前だけのインターフェイスを使用するのも適切ではないようです。

このようなメソッドにインターフェイス分離の原則を適用するにはどうすればよいですか?

4

2 に答える 2

0

次の回答は C# 言語に基づいています。別の言語では有効でない可能性があります。

取引先を表すインターフェースを作りたい

この最初の文は、おそらくインターフェイスは必要なく、トップレベルの抽象クラスが必要であることを示しています。そして、インターフェイスが必要か抽象クラスが必要かを区別することは非常に重要です。

抽象クラスは階層を表し、その階層の各子孫は特殊化されているため、ファミリを充実させるためにメンバーを追加できます。この場合、関係は「この XはY です」を表します</p>

インターフェイスは、どの階層にもリンクされていない一連の特性と動作を表します。したがって、主な目的は、同じ機能または動作を持つさまざまな種類のクラスをリンクすることです。この関係は、「この XはY を実行できる」ことを示しています</p>

したがって、あなたの説明により適しているのは抽象クラスであると仮定すると、次のことをお勧めします。

1 つのオプションとして、メソッド「getList()」および「setList()」を非抽象メソッドとして設定し、リストを格納するフィールドを抽象クラスに提供できます。

public abstract Partner
{
      List<Partner> list;

      public void SetList(List<Partner> list)
      {
          list = list;
      }
      public List<Partner> GetList(Partner partner)
      {
          return list;
      }
}

したがって、メソッド「Contains」も非抽象である可能性があるため、子孫クラスに強制的に実装を提供する必要はありません。

public bool Contains(Partner partner)
{
    return list.Contains(partner);
}

そして、将来、新しいヘルパー メソッドを追加したいとします。これらのメソッドは、基本クラスへの新しい非抽象メソッドになる可能性があるため、「パートナー」の現在の子孫には影響しません。

ヘルパー メソッドの実装を変更する必要がある場合は、下位クラスが基本実装をオーバーライドできるように、それを「仮想」として設定できます。

public virtual void AddPartner(Partner partner)
{
    list.Add(partner);
}
于 2018-08-27T14:33:22.953 に答える