1、对象的创建
面向对象的编程语言是用类(Class)来对现实世界进行抽象, 在运行时这些类会生成对象(Object)。
当然,单独的一个或几个对象根本没办法完成复杂的业务, 实际的系统是由千千万万个对象组成的, 这些对象需要互相协作才能干活,例如对象A调用对象B的方法,那必然会提出一个问题:对象A怎么才能获得对象B的引用呢?
最简单的办法无非是: 当对象A需要使用对象B的时候, 把它给new 出来 ,这也是最常用的办法, java 不就是这么做的?例如:
Apple a = new Apple();
后来业务变复杂了, 抽象出了一个水果(Fruit)的类, 创建对象会变成这个样子:
Fruit f1 = new Apple();Fruit f2 = new Banana();Fruit f3 = ......
很自然的,类似下面的代码就会出现:
Fruit f = null;
if("apple".equals(type)){
f = new Apple();
}else if("banana".equals(type)){
f = new Banana();
}
这样的代码如果散落在各处,维护起来将会痛苦不堪, 例如你新加一个水果的类型Orange, 那得找到系统中所有的这些创建Fruit的地方,进行修改, 这绝对是一场噩梦。
解决办法也很简单, 前辈们早就总结好了:工厂模式
public class FruitDatory{
public static Fruit create(String type){
if("apple".equals(type)){
return new Apple();
}
if("banana".equals(type)){
return new Banana();
}
return null;
}
}
工厂模式,以及其他模式像抽象工厂, Builder模式提供的都是创建对象的方法。
这背后体现的都是“ 封装变化”的思想。
这些模式只是一些最佳实践而已: 起了一个名称、描述一下解决的问题、使用的范围和场景,码农们在项目中还得自己去编码实现他们。
我们再来看一个稍微复杂一点, 更加贴近实际项目的例子:
一个订单处理类,它会被定时调用: 查询数据库中订单的处理情况, 必要时给下订单的用户发信。
public class OderProcessor(){
public void process(){
//单例方法获得OrderService对象
OrderService oderService = OrderService.getInstance();
//还是但例方法获得EmailService
EmailService mailService = EmailService.getInstance();
list<Order> orders = oderService.getOrders();
for(Order order : orders){
//判断order是否符合特定条件
//如果符合,就需要创建邮件,给用户发信
//代码略
orderEmail email = null;
//根据order对象来组建一个email对象
//逻辑复杂,代码略
// email = ......
mailService.sendMail(email);
}
}
}
看起来也没什么难度, 需要注意的是很多类一起协作了, 尤其是OrderProcessor , 它依赖于OrderService 和 EmailService这两个服务,它获取依赖的方式就是通过 单例方法。
如果你想对这个process方法进行单元测试-- 这也是很多优秀的团队要求的-- 麻烦就来了。
首先OrderService 确实会从真正的数据库中取得Order信息,你需要确保数据库中有数据, 数据库连接没问题,实际上如果数据库连接Container(例如Tomcat)管理的, 你没有Tomcat很难建立数据库连接。
其次这个EmailService 真的会对外发邮件, 你可不想对真正的用户发测试邮件,当然你可以修改数据库,把邮件地址改成假的,但那样很麻烦, 并且EmailService 会抛出一堆错误来,很不爽。
所有的这些障碍, 最终会导致脆弱的单元测试: 速度慢, 不可重复,需要手工干预,不能独立运行。
想克服这些障碍, 一个可行的办法就是不在方法中直接调用OrderService和EmailService的getInstance()方法, 而是把他们通过setter方法传进来。
public void setOrderService(OrderService orderService){
this.orderService = orderService;
}
public void setEmailService(EmailService emailService){
this.emailService = emailService;
}
通过这种方式,你的单元测试就可以构造一个假的OrderService 和假的EmailService 了。
例如OrderService 的冒牌货可以是MockOrderService , 它可以返回你想要的任何Order 对象, 而不是从数据库取。
MockEmailService 也不会真的发邮件, 而是把代码中试图发的邮件保存下来, 测试程序可以检查是否正确。
你的测试代码可能是这样的:
public void testOrderProcess(){
OrderProcessor op = new OrderProcessor();
op.setOrderService(new MockOrderService());
op.setEmailService(new MockOrderService());
op.process();
//做检查,看看结果是否正确,代码略
}
当然, 有经验的你马上就会意识到: 需要把OrderService 和 EmailService 变成 接口或者抽象类, 这样才可以把Mock对象传进来。
这其实也遵循了面向对象编程的另外一个要求: 对接口编程, 而不是对实现编程。
3、Spring依赖注册
啰啰嗦嗦说了这么多, 快要和Spring扯上关系了。
上面的代码其实就是实现了一个依赖的注入,把两个冒牌货注入到业务类中(通过set方法), 这个注入的过程是在一个测试类中通过代码完成的。既然能把冒牌货注入进去, 那毫无疑问,肯定也能把一个正经的类安插进去, 因为setter 方法接受的是接口,而不是具体类。
OrderProcessor op - new OrderProcessor();
op.setOrderService(new OrderServiceImpl());
op.setEmailService(new EmailServiceImpl());
op.process();
用这种方式来处理对象之间的依赖, 会强迫你对接口编程, 好处显而易见。
随着系统复杂度的增长, 这样的代码会越来越多, 最后也会变得难于维护。
能不能把各个类之间的依赖关系统一维护呢?能不能把系统做的更加灵活一点,用声明的方式而不是用代码的方式来描述依赖关系呢?
肯定可以, 在Java 世界里,如果想描述各种逻辑关系, XML是不二之选:
这个xml 挺容易理解的, 但是仅仅有它还不够, 还缺一个解析器(假设叫做XmlAppContext)来解析,处理这个文件,基本过程是:0. 解析xml, 获取各种元素
1、通过Java反射把各个bean 的实例创建起来: com.coderising.OrderProcessor , OrderServiceImpl, EmailServiceImpl.
2、还是通过Java反射调用OrderProcessor的两个方法:setOrderService(....) 和 setEmailService(...) 把orderService , emailService 实例 注入进去。
应用程序使用起来就简单了:
XmlAppContext ctx = new XmlAppContext("c:\\bean.xml");
OrderProcessor op = (OrderProcessor) ctx.getBean("order-processor");
op.process();
其实Spring的处理方式和上面说的非常类似, 当然Spring 处理了更多的细节,例如不仅仅是setter方法注入, 还可以构造函数注入,init 方法, destroy方法等等, 基本思想是一致的。
“不要给我们打电话,我们会打给你的(don‘t call us, we‘ll call you)”这是著名的好莱坞原则。
在好莱坞,把简历递交给演艺公司后就只有回家等待。由演艺公司对整个娱乐项目完全控制,演员只能被动式的接受公司的差使,在需要的环节中,完成自己的演出。
这和软件开发有一定的相似性, 演员们就像一个个Java Object, 最早的时候自己去创建自己所依赖的对象, 有了演艺公司(Spring容器)的介入,所有的依赖关系都是演艺公司搞定的, 于是控制就翻转了 Inversion of Control, 简称IoC。
但是IoC这个词不能让人更加直观和清晰的理解背后所代表的含义, 于是Martin Flower先生就创造了一个新词 : 依赖注入 (Dependency Injection,简称DI), 是不是更加贴切一点?