我知道盲目跟随任何“最佳做法”仍然会导致一堆严重遵守最佳做法的垃圾。 SOLID原则只是原则。它们并不适用于所有情况，但它们仍然是非常好的启发式方法，可以在您的代码中找到可能的改进。
他们的缺点是他们有时需要深入分析您的源代码才能应用它们。我和大多数程序员一样，一直在寻找更有效的做事方式，所以我很好奇是否有人听说过试图测试SOLID原则（或缺乏原则）应用的分析工具。
SRP 单一责任 原理
一个班级应该只有一个理由 更改。
OCP 开放式关闭 原理
软件实体（类，模块， 功能等）应该是开放的 延期，但关闭 修改。
LSP Liskov 替代原则
子类型必须是可替代的 他们的基础类型。
ISP 接口 隔离原则
客户不应该被迫依赖 他们不使用的方法。 接口属于客户端，而不属于客户端 的层次结构。
DIP 依赖倒置原则
抽象不应该依赖 细节。细节应该取决于 抽象。
- 从敏捷原则，模式和实践
答案 0 :(得分：7)
我不认为自动静态分析可以确定原则是否得到尊重。 要编写这样的工具，您需要正式定义每个概念的含义，并有办法根据任何代码进行检查。您如何正式确定责任的概念？我个人不知道。
也就是说，您可以使用工具来帮助您检测违规的可能性。 例如，您可以使用代码度量标准，例如每个类的方法数，每个类的成员数，以确定类是否太大，因此可能违反SRP。
Liskov替换原则可能是一个例外。 IF 你定义了所有方法的合同（前提条件，后置条件，不变量），然后你可以检查重新定义超类方法的方法是不是强化了前提条件，不要削弱后置条件和尊重超类方法的不变量。我认为工具ESC/Java执行这些检查。 必须执行wikipedia page about LSP次更多检查。
答案 1 :(得分：3)
我的回答涉及特定于.NET的产品，提前道歉，也许有人可以推荐其非.NET类似物。
我试试NDepend，看看是否可以通过使用以下指标来引导我违反SRP和ISP：
DIP和LSP违规可能更难追查，因为它们涉及程序员的意图。分析工具可以识别类型之间的关系，但是它如何能够说明一个类真正地从Square不正确地从Rectangle派生出来的另一个类？或者，在一个设计合理的程序中，A应该依赖于B而不是相反？
OCP提出了不同的挑战，因为该类应该打开/关闭的扩展/修改可能不一定已经发生。
然而，如果我们认为遵循SOLID导致产品更易于维护（科学证明这一说法不是这个问题的关键），那么NDepend的抽象性 - 不稳定性图表应该给出一个好的汇总度量每个软件模块遵循原则的程度。如果是的话，该模块应该避开图表的左下角，称为“疼痛区”。在该区域中，模块是稳定的（不是很好 - 太多其他人依赖它，所以很难改变），但不够抽象。