代码之家 › 专栏 › 技术社区 › Kenneth Cochran

是否有任何静态分析工具可以报告遵循可靠原则的程度?

solid-principles static-analysis

5

Kenneth Cochran · 技术社区 · 15 年前

我知道盲目遵循任何“最佳实践”仍然会导致一堆严格遵守最佳实践的垃圾。坚实的原则是, 原则

它们的缺点是有时需要对源代码进行深入分析才能应用它们。一、像大多数程序员一样,我一直在寻找更有效的做事方法。所以,我很好奇是否有人听说过一种分析工具,它试图测试是否应用了可靠的原则(或者缺乏)。

SRP公司 单一责任原则

原则

软件实体(类、模块、, 修改。

LSP公司 替代原理

子类型必须可替换为它们的基本类型。

网络服务提供商 接口分离原则

不应强迫客户依赖接口属于客户机,而不是

这个依赖倒置原理

抽象不应依赖于细节。细节应视情况而定抽象。

敏捷原则、模式和实践 作者:罗伯特·C·马丁。

2 回复 | 直到 5 年前

1

9

Trevor Reid Soumyajit Dasgupta 5 年前

我不认为自动静态分析可以确定这些原则是否得到尊重。要编写这样一个工具,您需要正式定义每个概念的含义,并有一种方法来对照任何代码检查它。你如何将责任的概念正式化?我个人不知道。

也就是说,你可以有工具来帮助你检测违规的可能性。例如,您可以使用诸如每个类的方法数、每个类的成员数等代码度量来确定类是否太大,从而可能违反SRP。

一个例外可能是Liskov替换原则。如果在所有方法(先决条件、后置条件、不变量)上定义契约,然后可以检查重新定义超类方法的方法是否加强了先决条件、削弱了后置条件并尊重了超类方法的不变量。我认为工具 ESC/Java 执行这些检查。阅读 wikipedia page about LSP 必须进行更多的检查。

2

4

azheglov 15 年前

我的回答涉及到一个特定于.NET的产品,提前道歉,也许有人可以推荐它的非.NET类似产品。

我会给你的 NDepend 一个尝试,看看它是否可以导致我违反SRP和ISP的使用指标,如:

异常多的方法
其他指标, full list of metrics here

DIP和LSP违规可能更难追踪,因为它们涉及程序员的意图。一个分析工具可以识别类型之间的关系,但是它如何判断一个类真正地扩展了另一个类的情况呢?或者,在一个正确设计的程序中,a应该依赖于B而不是相反?

OCP提出了一个不同的挑战,因为类应该被打开/关闭的扩展/修改不一定已经发生了。

然而,如果我们相信遵循SOLID可以得到一个更易于维护的产品(科学地证明这一说法并不是这个问题的目的),那么NDepend的抽象不稳定性图表应该给出一个很好的解释衡量每个软件模块遵循原则的程度。如果是的话,模块应该避开图表的左下角,被称为“疼痛区”。在这个区域中,模块是稳定的(不是很好——太多其他模块依赖它,所以很难更改),但是不够抽象。