基于interface的设计与基于POJO的设计

基于接口的设计作为一种好的设计模式，已经被广泛的获得认同。采用接口，我们可以更好的支持契约式的开发模式（虽然接口本身还缺乏一种良好的契约的描述能 力，更多的Contract实际上是通过文档、注释、或者设计模式的方式来进行补充），从而实现调用者和实现者之间的隔离。基于接口的设计对于OCP等原 则而言，也是一个必然的手段。

在Java的世界中，有很多的设计都是深度的应用了基于interface的设计的，比如：

1. JDBC API：API采用interface的方式，从Connection/DataSource出发，漫延到Statement, PreparedStatement,CallableStatemen,ResultSet,Metadata等等。不同的JDBC驱动程序可以提供不 同的实现，并通过工厂的模式进行选择。
2. JNDI API。于JDBC类似，实现的方式也非常的多，各有各的特色。比如说可以使用LDAP，Database，甚至把文件系统映射成为Context。可以集群，分布。想怎么复杂都可以，并一度成为J2EE的核心支柱。
3. DOM API。一个更为复杂的API，接口非常的多。完整的对XML进行了映射。

毫无疑问，基于接口的设计在很多的方面是取得了巨大的成功地，并且提供了一个完整的、优美的、高效率的解决方案。但是，也会有一些场合，会感觉到过渡的基于接口设计，可能带来的是一种滥用，导致更为复杂、更为低效。因此，在最近的一些技术中，开始对这个问题进行反思：

1. JDOM 是一个对DOM的反思，与DOM的基于接口的思维模式不同，JDOM直接把XML映射到一个POJO的模型中，包括Element, Attribute的类模型，不再使用复杂的工厂模式来创建对象，管理对象之间的复杂关系，反之，可以直接的、简单的创建、修改这些对象。当然JDOM能 够这样做，在一定程度上与其背景有关，DOM试图为跨语言、跨平台（基于Corba的思维模式）提供一个统一的API，而JDOM则更为自然的为Java 服务，更少包袱。JDOM被认为比DOM更简单、高效。（可惜，直到今天，JDOM仍然是JavaAPI中的一个二等公民，地位一直在DOM之下）。
2. JDBC与ADO相比，一直定位在一个更低的层次上，因此，在易用性一直存在不够，而ADO则通过Table/Row/Column的对象模型，支持一个相对简洁的开发模型。毫无疑问，在这里Table/Row/Column的对象模型具有POJO的很多性质。

一个低水平的设计人员会很少的考虑使用接口，什么东西都放到类中去完成（这也是一种典型的过程化思维模式），而一个高水平的设计人员则会充分的考虑如何使 用接口（对于我个人而言，我的接口的喜好胜过抽象类或者类的继承），但如果能够回归到改用POJO，就用POJO的时代，或许才是设计水平的进一步提升。

或如武侠文化中：手中有剑，心中无剑，乃习武第一层次。手中有剑，心中有剑，乃第二层次，手中无剑，心中有剑，可谓武林侠士了，但若为一代武林宗师，当进化到手中无剑，心中亦无剑阿。其实，程序如江湖。