Java Leaky抽象检查器

我正在考虑编写一个程序来检查
Java中的“漏洞抽象”.立即突然出现的一个领域是例外情况:

public class X
{
    // this one is fine, Readers throw IOExceptions so it is 
    // reasonable for the caller to handle it
    public void parse(final Reader r)
        throws IOException
    {
    }

    // This one is bad.  Nothing in the API indicate that JDBC 
    // is being used at all.
    public void process()
        throws SQLException
    {       
    }
}

注意,我不想要对已检查/未检查的异常的相对优点进行论证.我正在寻找的其他例子(不一定是异常处理)人们也可以通过检查源代码或类文件来合理地捕获它们.

我知道checkstyle,findbugs和PMD,而AFAIK都没有处理这个问题(我不反对将支票放入其中一个工具而不是自己编写).

您是否有任何其他泄漏抽象的例子可以静态检查?

编辑:

第二个错误的原因是该方法抛出异常,其中客户端无法知道正在使用JDBC(例如,它可能是任何东西).所以“漏洞抽象”是正在使用JDBC.如果底层机制改为soemthing(比如说JPA是一个不同的数据库抽象库)那么异常也都需要改变.因此,底层数据库库被泄露出去.

解决方法:

所以.

如何检测API是否泄漏实现细节或不保持相同的抽象级别.

您可能会观看this talk.它解释了API的外观和设计(您可以从良好实践中减去哪些不良做法)

例如

Functionality should be easy to explain.
If its a hard name it’s generally a bad design.

从中你可以发现,如果方法或返回参数给出详细说明,则它们不与抽象级别一起.

例如,高级方法

 -initProcess(): SGN_MTL

可能会泄漏返回值的实现细节.

这里的难点在于检测抽象级别何时发生变化.

例如,在你的方法中,如果它自己的代码是JDCB层的实现,那么可以全部抛出SQLExceptions.

您可以在此列表中看到更多这些主题的其他来源.
http://www.jetbrains.com/idea/documentation/inspections.jsp

查看“抽象”下的项目即.

>具体类的实例变量:将实例变量的类型声明为具体类而不是接口时的报告.

经典的例子是:

 private ArrayList list;

什么时候会更好

 private List list;
上一篇:Spring Boot入门系列(十五)Spring Boot 开发环境热部署


下一篇:idea热部署失败解决办法