11

R. Martin と M. Martin によるC# の Agile Principles, Patterns and Practices を読んでいるところです。インターフェース

例として、すべてのカスタム Gui クラスを含むGuiプロジェクトがある場合、それらのインターフェイスをInterfacesプロジェクトに保持します。具体的には、Guiに CustomButton クラスがあり、 ICustomButton インターフェイスをInterfacesに保持します。

利点は、ICustomButton を必要とするすべてのクラスが、Gui自体への参照を必要とせず、はるかに軽量なInterfacesプロジェクトへの参照のみを必要とすることです。

また、Guiプロジェクトのクラスが変更されて再構築が必要になった場合、CustomButton を直接参照しているプロジェクトのみ再コンパイルが必要になりますが、ICustomButton を参照しているプロジェクトは変更されないままになる場合があります。

私はその概念を理解していますが、問題があります:

私はこのインターフェースを持っているとしましょう:

public interface ICustomButton
{
    void Animate(AnimatorStrategy strategy);
}

ご覧のとおり、具体的なクラスである AnimatorStrategy を参照しているため、別のプロジェクトに配置されます。それをAnimationと呼びましょう。インターフェイス プロジェクトはAnimationを参照する必要があります。一方、AnimationがInterfacesで定義されたインターフェイスを使用する場合は、それを参照する必要があります。

循環依存 - 「ここに来ました」。

この問題の唯一の解決策は、インターフェイスで定義されたすべてのメソッドが、それ自体がインターフェイスである入力を受け取ることです。これを実装しようとすると、ドミノ効果が発生する可能性が高く、最も基本的なクラスであってもすぐにインターフェイスを実装する必要があります。

開発でこのオーバーヘッドに対処したいかどうかはわかりません。

助言がありますか?

4

4 に答える 4

1

すべてをインターフェイスとして宣言しても、パラメーターIBarを受け取るアセンブリFooのメソッドと、パラメーターIFooを受け取るアセンブリBarのメソッドがある可能性があるため、循環依存は避けられないと思います。

このための普遍的なレシピはないと思いますが、代わりに「常識」を使用して、必要に応じてアセンブリ内のインターフェイスを分割する必要があります。

于 2009-07-16T14:07:40.337 に答える