SOLID , SRP , IComparable

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

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

在SRP的上下文中，责任是对系统的交互者(即用户、角色或外部系统)的责任。如果您的系统有业务需求文档，那么至少应该在功能或非功能需求中推断出所有职责。如果不是，问问自己哪个业务所有者会要求您更改对象的配置方式。

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

如果你的icomibable/IDisposable实现需要改变，这种改变将由你的类的功能(业务)部分驱动，也需要改变(同时，出于相同的原因)。