当你看到这个界面时,你会将它拆分为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);
}
答案 0 :(得分:1)
你应该提出一个问题“为什么我们需要将接口分成2个独立的类和2个具体的类”。但是,如果它让您了解业务逻辑,那么您可以这样做。
从软件指标的角度来看,您拥有的凝聚力越强,您获得的阶级设计就越强大。有许多论文证明了这一假设。您可以参考此链接Introduce contents of cohesion metric
在您的情况下,我认为您应该将其拆分为两个界面来处理模板测试和测试计划。
答案 1 :(得分:0)
您应该为您必须面对的每个问题创建一个界面,并为您为此类问题创建的每个解决方案创建一个类。我将实现IUnitDataProvider的类实现为facade,在内部用更多的接口和类解决问题。但对于外观,你的界面似乎是对的。我看到的唯一问题是,如果TestPlan(和GetTestplanRootUnits)依赖于您的测试用例,我认为将它放在“域”接口中并不是一个好主意。将测试用例所需的内容放在问题域的接口或类中是可以的,只要您需要的东西实际存在并且在忘记测试需要它之后在问题域中有意义。如果你在问题域中找不到它,并且找不到不包含测试内容的名称,那么你应该考虑哪个问题域存在,并创建另一个接口&amp;你正在解决该领域的事情的课程。