大多数人进行SOLID软件设计讨论时都会很快变糟。我们最终为单一职责的“实际含义”而争辩或纠结，由于“开放/关闭”，我们某种程度上又需要抽象基类，并且由于“依赖倒置”，我们还向实体添加了接口。
除了使您的代码“遵循SOLID”之外，还有更多重要的问题需要关注。此外，当您对“原则”非常“虔诚”时，原则真的很危险。但这就是许多开发人员（包括我自己）在学习良好原则时想要努力的方向。
对我而言，设计质量是：如果我的假设前提是错误的，更改结果有多容易？如果应用程序周围的所有内容（框架，数据库，远程Web服务等）都消失了，这些代码是否还能生存？该代码的行为是否由代码本身以外的其他东西指定？
众说纷纭：
当有人在争论SRP时，对我有用的是让整个团队坐下来，并征求所有人的意见，以定义对团队意味着什么。两位辩论者都必须愿意同意团队的协议（因为一致性才是真正重要的）。
那绝对是处理它的一种方式。我同意人们应该就重要事项达成共识，并采取相应的行动。每当情况似乎并非如此时，最好花点时间进行调整。