我知道盲从任何“最佳实践”仍可能导致垃圾的臭一堆严格遵守最佳实践。 SOLID原则是正义的， 原则 。 他们并不适用于所有情况，但他们仍然在你的代码中发现可能的改进非常好的启发。
缺点给他们的是，他们有时也需要您的源代码进行了深入分析应用它们。 我最喜欢的程序员经常是在寻找做事更有效的方式，所以我很好奇，如果任何人听说过一个分析工具，试图测试的SOLID原则（或缺乏）的应用程序。
SRP 单一职责原则
一个类应该只有一个理由去改变。
OCP 开-闭原则
软件实体（类，模块，函数，等等）应该对扩展开放，但对修改关闭。
LSP 的里氏替换原则
子类型必须为替代他们的基本类型。
ISP 接口分离原则
客户端不应该被迫依赖于它们不使用的方法。 接口属于客户，而不是层级。
DIP 依赖倒置原则
抽象不应该依赖于细节。 详细情况应取决于抽象。
- 从敏捷原则，模式与实践
我不认为自动静态分析可以确定的原则得到尊重。 写这样一个工具，你就需要正式定义了每个概念的意思是，有一个方法来检查它反对任何代码。 你会如何形式化一个责任心的概念？ 我个人不知道。
这就是说，你可以有工具来帮助您检测违反的相似性。 例如，你可以使用代码指标，如每类方法数，确定每类成员的数目，如果一类是太大，因此可能违反SRP。
一个例外可能是里氏替换原则。 如果你定义的所有方法的合同（前置条件，后置条件，不变量），那么你可以检查重新定义超类的方法的方法不加强的前提下，不削弱后置条件，尊重父类的方法的不变量。 我认为工具ESC / Java的执行这些检查。 阅读关于LSP维基百科页面更多的检查必须进行。
我的答案涉及特定.NET产品，道歉提前，也许有人可以建议其non-.NET类似物。
我给NDepend的一个尝试，看看它是否可以通过使用指标，如导致我违反SRP和ISP的：
DIP和LSP违规可能更难追查，因为它们涉及到程序员的意图。 分析工具可以识别类型之间的关系，但它怎么能告诉其中一个类真正扩展了另一个从广场的不适当获得从矩形的情况吗？ 或者，在适当设计的程序，应该依赖于B和不是其他的方式？
OCP呈现出不同的挑战，因为扩展/修改的类应该是打开/关闭，未必已经发生。
但是，如果我们认为以下的潜在客户，以更易于维护的产品（科学证明这种说法是不是这个问题是关于什么的），然后NDepend的的抽象性，不稳定性图表应该给的原则是如何遵循每个软件良好的综合衡量模块。 如果他们是，该模块应该避免图表的左下角，被称为“痛苦之区”。 在该区域中，该模块是稳定的（不是一个好办法 - 太多的人依赖于它，所以它很难改变），但没有足够的抽象。
