固体，SRP，IComparable

Question

好的，在单个类上实现IComparable和其他接口(如IDisposable)违反了SRP原则。

SRP指出，每个类都应该实现一个信号响应，方法应该在很大程度上相互关联，以实现内聚类。

比较不是另一种反应吗？

如能作出一些澄清，将不胜感激。

Answer 1

如果我是你，我会试着坚持SRP，但不要太严格，因为努力最终会适得其反。所以现在说，你应该怎么做？要么实现IComparable并将比较完全封装在对象中，要么有一个单独的比较器并在其中实现比较逻辑。现在作为比较，就SRP而言，如果比较是相当基本的，并且不应该受到更改，我将实现IComparable并完成它。如果您能够合理地预见将来的一些变化，或者如果比较是依赖于用例的，那么我将选择比较器路径。最终的目标是开发封闭的组件，并使它们通过组合来协作，所以如果比较没有多少机会改变，那么组件就可以关闭，您将不会再听到它。您还可以在代码中对IComparable的使用进行注释，如果将来发生了一些更改，则切换到使用比较器进行组合，因为据说没有发生的更改确实发生了。

Answer 2

我认为，IComparable和IDisposable的冲击根本不是的责任，因此不会违反SRP。

在SRP的上下文中，责任是对系统的一个交互者(即用户、角色或外部系统)负责。如果您的系统有业务需求文档，则至少应该在功能需求或非功能需求中推断所有责任。如果不是，问问自己哪个企业主会要求你改变一个对象如何处理自己。

在我学习了SRC之后从事的第一个项目中，我们将其解释为“每个类一个公共方法”，并将其作为一项严格的规则加以应用。虽然这使得保持“遵从性”变得很容易，但我们最终得到的代码比需要的要复杂得多。

如果您的IComparable/IDisposable实现需要更改，则该更改将由类的Functional(Business)部分驱动(同时也出于相同的原因)。