一个对象的类型太多

为了能够证明代码的气味，你必须回答（用括号表示正确答案）：

• 所讨论的物体是否用于实现十二种不同的目的？是
• 这些目的是否过于密切相关？否
• 那个物体有没有从未使用过的海豚？否
• 该对象是否有很少使用的目的，可以作为更通用目的的一部分？否
• 是否存在根本不是目的而只是运行时使用的标记的目的？否

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

正如您所说，这不是一成不变的，但它绝对值得一看。我认为回答您的问题的最佳方法是用另一个问题："每个类都有明确定义的目的和职责吗？"如果答案是肯定的，那么可能是设计很好，或者最坏的情况是，接口太细。

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

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

通常，这种事情是动态、敏捷系统的一个特征。也就是说，它的功能是随着时间的推移而演变的。

此外，我认为这是一个标志，表明设计师正在以良好的OO方式进行思考。

这并不是说代码不能重构，一些接口定义不能合并，事实上，由于所有的接口定义，这项任务现在变得容易多了。想象一下，尝试以其他方式重构对象！

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

一个为急救人员（警察、消防等）提供路线和建议的应用程序有一个类Mapping，它可以：

• 地理编码和反向地理编码（将lat&long转换为地址，反之亦然）
• 将地图图像绘制到屏幕上，并突出显示交通和路线
• 查找不同位置之间的路线
• 分析第三方数据源提供的流量模式

系统的最初设计者一定认为"好吧，这些都是与地图和位置相关的任务，所以是的，这应该是一个类"。不幸的是，这使得以后不可能更改其中一个功能，因为所有东西都是紧密耦合的。

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

• Geocoder
• 地图渲染器
• RouteRenderer
• RouteBuilder
• TrafficRenderer（继承自RouteRenderer）
• TrafficDatasource

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