一个对象有多少种类型太多了？

Question

我意识到这个问题并没有完全切割和干燥，但总的来说，你怎么知道一个对象何时有太多类型？

我目前正在支持一个我不熟悉基线的项目，但我的任务是基本上修复错误，以减少SPR数据库中的项目数量。我不断遇到扩展许多不同接口的类，包括一个这样的类，总共扩展了12个。许多其他人延伸7或8。

现在我知道依赖接口而不是具体实现是一种很好的设计实践，但是这太过分了吗？这是一个真正的代码气味，可能是一个糟糕的设计标志，或者我只是反应过度，根据情况，一个类延伸七个，八个甚至十二个不同的接口是正常的吗？通过基线试图追踪实现12个接口的对象的实际具体类型是累人的。

Answer 1

正如你所说，这不是切割和干燥，但它绝对值得一看。我认为回答你问题的最好方法是另一个问题：“每个班级都有明确的目的和责任吗？”如果答案是肯定的，那么可能是设计很好，或者最坏的情况是，界面太过细化。

为了帮助您解决搜索问题，是否有IDE可以加载代码以帮助可视化和导航继承树？

Answer 2

为了能够证明您必须回答的代码气味（在parethesis中正确答案）：

• 有问题的对象是否用于实现十二个不同的目的？ YES
• 这些目的是否过于密切相关？ NO
• 那个物体是否有从未使用过的物品？ NO
• 那个很少使用的对象的目的是否可以成为更通用的目的的一部分？ NO
• 有没有目的的目的，只是运行时使用的标记？ NO

可能有更多问题要回答，请随意添加评论。

Answer 3

虽然粒度接口定义很难维护，但在我看来，我并不认为这是糟糕设计的标志。

通常这种事情是动态，敏捷系统的特征。即其中一个功能是随着时间的推移而发展。

此外，我认为这表明设计师正在以良好的OO方式思考。

这并不是说代码无法重构并且某些接口定义合并，实际上由于所有接口定义，这现在是一个更容易的任务。想象一下，试图重构对象！

Answer 4

一个类可以扩展12个接口，但如果这12个合同代表一个行为的交集，使得该对象仍然只有一个责任，那就是A-OK。在大型企业项目中，一次又一次地，最难以维护的部分是尝试做太多不同事物的类。这是一个例子：

为第一响应者（警察，消防等）进行路由和推荐的应用程序有一个类映射，其中包含：

• 地理编码和反向地理编码（将lat＆amp; long转换为地址，反之亦然）
• 将地图图像绘制到屏幕，并显示流量和路线“突出显示”
• 在不同地点之间寻找路线
• 分析第三方数据源提供的流量模式

系统的原始设计者必须考虑“好吧，这些都是地图和位置相关的任务，所以是的，这应该是一个类”。不幸的是，由于一切都紧密耦合，因此无法在以后更改其中一项功能。

在应用程序中的各种组件提供的功能中查找接缝。将这些接缝分离为组件之间的内聚合同（接口），其中每个单元能够向其消费者提供有价值的“服务”（不是在web服务意义上）。回到我之前的例子，我们最终将Mapping类（Project Yoko）分解为：

• 地理编码
• MapRenderer
• RouteRenderer
• RouteBuilder
• TrafficRenderer（继承自RouteRenderer）
• TrafficDatasource

单个组件具有runtime resolved dependencies，这使我们能够引入单元和系统测试，在预先存在的路由逻辑中发现几个错误，此外还提供许多其他好处。一般来说，如果你能在一个班级中看到责任的逻辑分离，你可能应该将其分解。

Answer 5

查看.Net的System.Collections.Generic命名空间中的一些类 - 其中许多类支持7+接口。从设计的角度来看，这不是什么值得担心的事情。类应该实现它要实现的任何和所有接口。

因此，类应该实现的接口数量没有数字限制。唯一的问题是这些接口是否对该类有意义。

Answer 6

正如Eric指出的那样，最糟糕的情况是接口过于细化。这听起来像是这样的。 IMO从纯粹的设计角度来看，它与数据库过度规范化的问题相同。如果你可以设法整合许多界面，即使有些东西是多余的，如果你可以这样做而不会损失可管理性，你应该这样做。

Answer 7

我想说这很大程度上取决于这些接口所涵盖的服务范围有多广。 interface segregation principle鼓励将大型接口拆分为更小，更高度内聚的接口，这些接口可能支持一小组服务。如果您正在使用的代码库中的接口就是这种情况，并且接口在组合时创建逻辑服务分组，那么这可能不是什么大问题。如果接口很大或在分组时看起来完全不同，那么您正在处理可能存在缺陷的设计。