0

ソリューションの複数の部分からアクセスする必要がある共有構成があるプロジェクトで作業しています。

Config モジュールを担当するチームは、2 つのクラスだけで構成されるインターフェイスを実装しました。(プロパティを介して) 特定の値を取得、キャッシュ、および提供する 2 つのクラス。

これは悪い設計だと思います。私の意見では、この動作を実装する実際のクラスではなく、インターフェイスを介してアクセスできるすべての構成値を定義する方がよいでしょう。

私の意見では、構成値を取得するようなものについては、アクセスできる値を示すインターフェイスを提供する方が論理的ですが、クラス (たとえば、プロパティがインターフェイスによって制御されない実装) は提供しません。

-編集 - インターフェイスは次のようになります。

public interface IConfigurationResolver
{
    GeneralConfiguration GetGeneralConfiguration(string Id);
    SpecificConfiguration GetSpecificConfiguration(string Id);
}

1 つのクラスで実装されます。私が言いたかったのは、このインターフェイスは実際には、それぞれが構成値を提供する責任を持つ 2 つのクラスを定義しているだけであるということです。一方、インターフェイスがそのような詳細を気にせず、構成値自体を提供する必要がある場合は、より良いと思います。

これらは非常に経験豊富な開発者ですが、私はそうではありません。

4

3 に答える 3

1

ここではかなりの数のことが起こっています…

インターフェース内の非抽象クラスの参照はIConfigurationResolverコードの匂いであり、「実装ではなくインターフェースへのプログラム」の原則に違反しています (「インターフェースへのプログラム」とはどういう意味ですか? )。

インターフェイスを介して構成パラメーターを明示的に明らかにしたいというあなたの希望は良いものであり、(Eric Evans のDomain Driven Designで説明されているように) Intention Revealing Interfaceの概念に従っています。

ただし、非常に多くの構成値がある場合、このインターフェイスには非常に多くのメソッドが含まれる可能性があります。これが、ドメインの知識の出番です。「構成の世界」を、アプリケーションの個別の側面を構成するために使用されるまとまりのあるインターフェースのセットに分解することは、それ自体がスキルであり、SOLIDの「私」。Lowy のProgramming .NET componentsでは、コントラクトのリファクタリングの問題について説明しており、大まかなガイドとして、インターフェイスごとに 3 ～ 5 つのメソッドを目指すことを提案しています。

「構成をリファクタリングしたい」という欲求が、現在のインターフェースに 2 つのメソッドが存在する根底にあると推測しています。

于 2013-05-20T13:59:36.220 に答える
0

SOLID 原則の 1 つは、インターフェイス分離の原則です。「多くのクライアント固有のインターフェイスは、1 つの汎用インターフェイスよりも優れています。」</p>

http://en.wikipedia.org/wiki/SOLID_%28object-directional_design%29

「2つのクラスだけで構成されるインターフェース」とはどういう意味ですか? このインターフェイスを実装するクラスは 2 つだけですか?

これは悪い設計だと思います。私の意見では、この動作を実装する実際のクラスではなく、インターフェイスを介してアクセスできるすべての構成値を定義する方がよいでしょう。

あなたの質問を理解できません - はい、クラスを直接参照するのではなく、インターフェイスを参照する必要がありますか?

于 2013-05-20T11:31:27.817 に答える