转 接口滥用问题

我们知道，大家提倡面向接口编程，但凡事都有个度，当滥用，那么面向接口完全流于形式。

 

一.首先，我们先讲一下面向约定编程。

企业编程中，都有一定的项目分层编程规范，如前台与后台逻辑之间的联系通过定义接口来完成。

正如我们平时使用的 MVC三层模形，service层，dao层很多都使用接口，那么新来者肯定也要遵守规范，在这三层使用接口。

就是大家约定成俗都使用接口而已。但请确记，你这不是面向接口编程，而是面向约定编程.

为什么这样说呢，请后面听我道来。

 

如果有如下几个特点，那么面向接口编程是流于形式的。

1. 定义的接口没有经过大脑设计

没有考虑是否有多实现，完全遵从于大家都是这样使用，那么可以确认，你现在是面向约定编程。

 

2. 接口方法过多

精心设计的接口，接口方法一般比较精简，才可能有多个实现类。而我们平时的业务接口，如果没有将不变及需要变化的接口分离，通通塞在一个大的接口类中，即使有多实现，这种结构也是不合理的，再次确认这种接口完全是遵照某种约定。

 

3. 是否符合面向接口的目的

使用接口的目的是"定义一个接口，可以有多个实现",因为你有可能连这个目的都不符合。

举一个例子

1。如我们有一个 UserDao接口,及一个IbatisUserDaoImpl实现，如果我们有跨数据库的使用需求(同时支持mysql,oracle),根据ibatis实际的使用需求，我们其实是不会有多个IbatisUserDaoImpl实现的，

因为实际的效果是，我们通过同一个实现类，只需要在执行查询时路由至不同的sqlmap及dataSource就行了，而一般不会做 IbatisOracleUserDaoImpl及IbatisMysqlUserDaoImpl这种实现方式。所以说你是使用ibatis的话，一般也是没有必要使用接口的。

2。如果你定义的接口UserDao,那么实现类的名称为 IbatisUserDaoImpl,HibernateUserDaoImpl,那么也是有问题的，既然已经选择的一个技术框架(Ibatis或者Hibernate),一般不会出来切换技术实现的需求，跨数据库倒比较实际，如MysqlUserDao,HibernateUserDao.

 

 

二.撇开扩展性，那使用接口又有啥好处呢？

1. 通过接口比较容易浏览所有的接口方法，即没有繁杂的实现代码，更易于看懂

2. 接口不能实例化，避免使用者直接实例化后使用（类就有这种问题，直接实例化使用往往是错误的）

 

以上两个好处，也有足够理由支持我们使用接口。

 

三.那么我们应该怎么做？

1。除了面向约定使用的接口，其它的业务逻辑代码，如果没有必要使用接口的就不要使用接口，减少类的数量（太多类看着也很累人的）

2。如果定义的接口方法过多，重新审视一下，是否应该改进设计

 

 

如果接口的不同实现处理了有相同规则但完全不同的业务，考虑用接口。

如果不同实现处理了相同的事情，但只是拿新的实现替换了旧的实现，建议不要使用接口，直接将原来的实现覆盖即可。

 

接口的最简单初衷是要将“做什么”和“怎么做”进行分离