自定义接口及实现与实现类解耦

在开发Java系统时，很难避免使用第三方类库，比如 缓存程序，Java Mail，等

 

自定义cache接口实现与缓存框架解耦

http://www.iteye.com/topic/697343

 

一文让我觉得这个理念应当可以应用于更加广泛的场合。

 

在上文中有人提到

“自定义接口的做法等同于创造标准，在没有规范标准的缓存框架中创造标准很难。”

 

将自定义接口称之为创造标准倒也不为过，不过这个标准是以当前系统的调用方式为导向的，使用范围也只是当前系统，并不是以兼容所有实现类为导向的，所以从一般标准的范围来看，自定义接口我认为算不上标准，自定义接口只是为了将自己的系统与实现类解耦，并不是为了兼容所有实现类而创建的标准。

 

因此，我觉得如果一个功能存在多种类型的实现类，这些实现类可能表现为不同的适用场景，例如缓存系统，此时最好应当将自己的系统与实现类解耦。

 

另外从易用的角度来看，如果实现类的API过于复杂，如SUN的Java Mail API，重新定义一套符合自己系统的API也有助于让调用部分的代码更清晰。

 

从可复用的角度来讲，通过自定义功能清晰的API，更有助于该API的复用。由于API与实现类分离，从而就可以根据系统需求来配置一个功能API的实现类，比如缓存系统，就可以根据实际需求在系统中的不同位置采用不同的缓存系统。这也正是IoC带来的优点。

 

然而在传统Java系统中，即便是使用了IoC，实现类的类名一样还是会出现在配置文件中，如果配置了若干实现类，那么在更换实现类时必须知道需要将哪几个实现类替换掉，从而增加了实现替换的复杂度。

 

借助JIOPi，可以让这一过程变得更加容易。

 

下面是一个自定义的邮件发送的API的调用示例

 

MyMailSender.sendMyMail("姓名<[e-mail]>", "hello", "content test");   

借助JIOPi忽略实现类的特性，系统的lib目录只需一个MyMailAPI.jar，而无需部署javamail.jar，以及相关实现类的Jar包，让lib目录更易于管理

其中 MyMailSender 是 MailSender 接口的伪实现类，因为接口不能定义static方法，因此在伪实现类中增加static方法简化方法调用，借助JDK1.6的新特性，MyMailSender 的依赖注入不再依赖任何第三方API，当需要更换实现类时，只需要更改配置文件，而无需更改 MyMailSender 的代码

详细介绍请参阅：

http://jiopi.iteye.com/blog/693423