好的，实现IComparable和其他接口（如IDisposable）在单个类上是否违反了SRP原则。
SRP规定每个类应该实现单一职责，方法应高度相互关联以实现内聚的类。
难道比较不是另一个职责吗？
希望能够提供一些澄清。
SOLID , SRP , IComparable
4
- Zack ISSOIR
1
那么ISP呢？SRP和ISP都是SOLID的一部分，因此不应该发生冲突。 - Ivan Stoev
2个回答
4
如果我是你，我会尽量遵守SRP，但不要过分追求。那么现在，你该怎么办呢？要么实现IComparable并将比较完全封装在对象中，要么使用单独的比较器并在其中实现比较逻辑。 对于比较而言，就SRP而言，如果比较相当基本且不应受到更改的影响，我会实现IComparable并完成它。如果您可以合理地预见未来的一些变化，或者比较取决于用例，则我会选择比较器路线。最终目标是开发封闭的组件，并通过组合使它们互相配合。因此，如果比较几乎不会改变，那么组件可以关闭，您就不必再关心它了。您还可以在代码中注释使用IComparable，并且如果未来发生了一些变化，则切换到使用比较器进行组合，因为被认为不会发生的变化确实发生了。
- Arthur Noseda
2
1谢谢，坚持这些原则不应该太严格。这取决于情况。那实体之间的比较呢？ - Zack ISSOIR
1SOLID是一种工具，而不是达到目的的手段。此外，您通常需要在严格性和宽容之间做出选择。您无法预见所有变化，因此应保持简单。在我看来，过于严格的SRP会让您过度设计事物。就实体而言，如果您所说的实体是持久对象，那么我之前写的仍然适用。这取决于变化的相似性以及对某些用例的依赖性 - 未来是否会有不同的用例对同一实体进行不同的比较。 - Arthur Noseda
3
我认为IComparable和IDisposable的实现根本不是责任，因此不会违反SRP。
在SRP的背景下，责任是对您系统的互动者（即用户、角色或外部系统）的一种责任。如果您的系统有业务需求文档，则所有责任都应至少隐含在功能或非功能需求中。如果没有，请问自己哪个业务所有者会要求您更改对象如何处理自身。
在我学习SRC后参与的第一个项目上，我们将其解释为“每个类一个公共方法”，并将其视为硬性规则应用。虽然这使得保持“合规”变得容易，但最终导致了比必要复杂得多的代码。
如果您的IComparable/IDisposable实现需要更改，则该更改将受到业务部分（原因相同且同时需要更改）的驱动。
在SRP的背景下，责任是对您系统的互动者（即用户、角色或外部系统）的一种责任。如果您的系统有业务需求文档，则所有责任都应至少隐含在功能或非功能需求中。如果没有，请问自己哪个业务所有者会要求您更改对象如何处理自身。
在我学习SRC后参与的第一个项目上，我们将其解释为“每个类一个公共方法”，并将其视为硬性规则应用。虽然这使得保持“合规”变得容易，但最终导致了比必要复杂得多的代码。
如果您的IComparable/IDisposable实现需要更改，则该更改将受到业务部分（原因相同且同时需要更改）的驱动。
- yelxe
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接