0

このインターフェイスを見たら、2 つのインターフェイスと 2 つの具象クラスに分割しますか? または、1 つのインターフェイスと 1 つのクラスを作成しますか。

2つのメソッドのためだけに別のインターフェースとクラスを作成するのはオーバーヘッドのように思えますが、まあ...

そのような場合にどのように対処するか、別のアイデアはありますか？

public interface IUnitDataProvider
{
        // Testplan methods
        IEnumerable<Unit> GetTestplanRootUnits(int templateId, int testplanId);        

        // Template methods
        IEnumerable<Unit> GetTemplateRootUnits(int templateId);
        void AddUnit(Unit unit);
        void DeleteUnit(int unitId);
        bool UnitExists(string unitName, int templateId);

        // Mutual methods
        IEnumerable<Unit> GetChildrenUnits(int templateId, int parentId);
}
4

2 に答える 2

1

「なぜインターフェイスを 2 つの個別のクラスと 2 つの具象クラスに分割する必要があるのか​​」という質問をする必要があります。ただし、ビジネスロジックを理解できるようになれば、それは可能です。

ソフトウェア メトリックの観点からは、まとまりがあればあるほど、強力なクラス設計が得られます。仮説を証明した論文は数多くあります。このリンクへの参照がいくつかある可能性があります凝集度メトリックの内容を紹介します

あなたの場合、テンプレート テストとテスト計画を処理するために、2 つのインターフェイスに分割する必要があると思います。

于 2012-07-15T10:08:47.187 に答える
0

直面しなければならない問題ごとにインターフェイスを作成し、そのような問題に対して作成するソリューションごとにクラスを作成する必要があります。IUnitDataProvider を実装するクラスをファサードとして実装します、より多くのインターフェイスとクラスを使用して内部的に問題を解決します。しかし、ファサードの場合、インターフェースは正しいようです。私が見る唯一の問題は、TestPlan (および GetTestplanRootUnits) がテスト ケースを再参照する場合、そのように "Domain" Interface に入れるのは良い考えではないと思います。テスト ケースに必要なものを問題ドメインのインターフェイスまたはクラスに配置してもかまいません。ただし、必要なものが実際に存在し、テストに必要であることを忘れた後でも、問題ドメインにそれ自体で意味がある場合に限ります。問題のドメインでそれが見つからず、Test something を含まない名前が見つからない場合は、おそらくどの問題のドメインにそのものが存在するかを考えて、別のインターフェイスとクラスを作成する必要があります。そのドメインのあなたが解決していること。

于 2012-07-15T14:33:27.137 に答える