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 个具体类”。但是，如果它使您了解业务逻辑，则可以这样做。

从软件度量的角度来看，您拥有的凝聚力越强，您获得的类设计就越强大。有许多论文证明了这个假设。您可以对此链接进行一些参考Introduce contents of cohesion metric

在您的情况下，我认为您应该将其拆分为两个接口来处理模板测试和测试计划。

于 2012-07-15T10:08:47.187 回答
0

您应该为您必须面对的每个问题创建一个接口，并为您为此类问题创建的每个解决方案创建一个类。我将实现 IUnitDataProvider 的类作为外观，用更多的接口和类在内部解决问题。但是对于外观，您的界面似乎是正确的。我看到的唯一问题是，如果 TestPlan（和 GetTestplanRootUnits）对您的测试用例进行冷藏，我认为将它放在“域”接口中不是一个好主意。可以将测试用例所需的东西放在问题域的接口或类中，只要您需要的东西确实存在并且在问题域中本身就有意义，在忘记测试需要它之后。如果您在问题域中找不到它，并且找不到不包含 Test something 的名称，那么您可能应该考虑该事物存在于哪个问题域中，并为它创建另一个接口和类你正在解决的那个领域的事情。

于 2012-07-15T14:33:27.137 回答