再论机械式针对接口编程

两月前论及到 针对接口编程及敏捷编程,如今再一次老调重提。面向对象有一个很重要设计原则:

针对接口编程,而不是针对实现编程

这一原则关键在于理解什么是接口,请参照前文提到的上一篇。因为 Java 语言中有 interface 这个概念,于是 Java 的 interface 便躺枪了,好好的针对接口编程在 Java 中就机械式的变成了针对 interface 的编程。

以致于只要有实现的地方都可能变成像 UserDao.java(接口) 与 UserDaoImpl.java 成对出现,在以后的重构中基本上是为了实现而修改接口,这也进一步违背了针对接口编程的初衷,接口怎么一点也不稳固。

或许有人认为先声明一个 interface,然后我们可能会有多种实现(为将来考虑,不过多数时候只会是单一实现),这很像是 interface 存在的一个理由。可是当我们写下类似 UserDaoImpl 这个样的实现类名时直接宣告了该接口其实就只有一种实现,不然的话再加一个实现的话类名为哪般?UserDaoImpl2? 显然多种实现时 UserDaoImpl 需要重命名了。

既然 UserDao(interface) + UserDaoImpl 这种模式下,首先 UserDao 无法称之为真正的接口,并且有新实现加入时不可避免要重构,那何不在只有一种实现是先只需声明 UserDao 实现类即可,待到有新实现时抽取出接口来。这才应该是最小化,快速敏捷式编程。

UserDao(interface) + UserDaoImpl 也并非总是有问题,当 UserDao 是一个真正的外部接口(稳固的,而向外部系统的协议),而它只有一种实现的话实现类名命作 UserDaoImpl 并无异议。

但是通常我们的 UserDao(interface) + UserDaoImpl 模式只是把更新先进了 Java 语言设计倒退为 C++ 的头文件与源文件的分离行为。C++ 由于语言本身的特性需要把方法声明与实现分别写在 .h 和 .cpp 文件中去,#include 时我们只会包含 .h 文件。

与 C++  类比发现,如果我们机械式的认为 UserDao(interface) + UserDaoImpl 就是在做针对接口编程,那不过是傻傻地把 UserDao(interface) 当成了 C++ 的 .h 文件, UserDaoImpl 当成了 C++ 的 .cpp 文件而已。

Java 的 import 可比 C/C++ #include 智能,重复交叉引用都不是事,所以并不存在一个真正接口的情况下,完全可以只声明一个 UserDao 类,依照整洁代码的要求把 public 方法前移别人自然就清楚 UserDao 类应如何使用。public 方法就是被暴露的他人可以自由调用的方法,无须勉强的通过一个 Java interface, 像 C++ 的 .h 文件那样来暴露方法。

最后想像一下,在 UserDao(interface) + UserDaoImpl 模式下,UserDaoImpl 除了应该现的接口方法外,其余方法都必须是 private 了,否则就尴尬了。当然也可以把 private 去掉变成 package-private, 以此向它的单元测试作出让步。


2017-08-17: 重新理解,纠正一下上面那一句,应该说 UserDao(interface) + UserDaoImpl 模式对测试应该是更友好的,因为使用者关注接口中的 public 方法,而在 *Impl 类中的非接口方法可以放心的变为 package-private, 方便于测试,还不影响别人怎么调用。只有一个实现类的话,package-private 可能被别人直接调用了。

类别: Programming. 标签: . 阅读(19). 订阅评论. TrackBack.

Leave a Reply

Be the First to Comment!

avatar
wpDiscuz