??xml version="1.0" encoding="utf-8" standalone="yes"?>
]]>
代码1Q?/FONT>
我觉得面向对象很好地解决了Y件系l中职责划分的问?SPAN lang=EN-US>.借助于面向对?软g开发h员一般的,都可以将需求里的名词{换成pȝ中的对象,动词转换为对象里的方?q样非常W合人的思维方式,非常自然.
但是,问题是某些需求却偏偏不是能用q样的”名词”和”动词”就能完的描述出来?假如q样的问?需要对pȝ中的某些Ҏq行事务处理,q种需要事务代码散布在多个cM.面对q种需?应该怎么办呢?最直接的办法就?创徏一个基c?接口)或者一个助?事务处理的功能攑֜其中,q让所有需要事务功能的cȝ承这个基c?接口)或者用这个助?加入q样?需要修改的地方׃分散在多个文件中.q样大的修改?无疑会增加出错的几率,q且加大pȝl护的难?如图:
因此,面向斚w的编E?Aspect Oriented Programming,AOP)应运而生.AOP为开发者提供了一U描q横切关注点的机?SPAN lang=EN-US>,q能够自动将横切x点织入到面向对象的Y件系l中Q从而实C横切x点的模块?通过划分Aspect代码,横切x点变得容易处?开发者可以在~译时更?插入或除ȝl的Aspect,甚至重用pȝ?/SPAN>Aspect.?OOP只用于表C对象之间的泛化-特化(generalization-specialization)关系(通过l承来表?,而对象之间的横向兌则完全用AOP来表?SPAN lang=EN-US>. q样,很多l对象之间横向关联增加灵zL的设计模式(例如Decorator{?SPAN lang=EN-US>)不再必??如图:
想一想以前在使用工厂模式的时?SPAN lang=EN-US>,在最早的情况?每个工厂可能都是一?/SPAN>Singleton,生成对象的代码被写死在了c里?SPAN lang=EN-US>.后来Z觉这栯是耦合E度太高,q不够灵z?所以把对象的类名写在一?/SPAN>XML文g?SPAN lang=EN-US>,q样一?问题又来?每个工厂都有自己的读取配|文件的代码,通过dXML文g,或者通过dProperties,工厂里充满了qp的和业务逻辑完全不相关的配置理代码,l护h很不方便,.?/SPAN>Spring通过?/SPAN>lg工厂?/SPAN>把这些都集成在了一?SPAN lang=EN-US>,用一个统一?/SPAN>BeanFactory来管理这些配|?SPAN lang=EN-US>,而且提供了更高一U的抽象:ApplicationContext
Ioc好像很神奇的样子,其实原理和实现都很简?是要使用的对象都用XML来定?用反来生成,用注的方式来? 其实Ioc是工厂模式的升华Q?/SPAN>Ioc可以被看作是一个大工厂Q只不过q个大工厂里要生成的对象都是?/SPAN>XML文g中给出定义的Q然后利?/SPAN>Java?SPAN lang=EN-US>“反”编E,ҎXML中给出的cd生成相应的对象。从实现来看Q?/SPAN>Ioc是把以前在工厂方法里写死的对象生成代码,改变为由XML文g来定义,也就是把工厂和对象生成这两者独立分隔开来,目的是提高灉|性和可维护性?SPAN lang=EN-US>
Template模式主要是用来解册L一个问?SPAN lang=EN-US>:当你知道法的具体步?但不知道如何L行这些步?Template把如何执行这些步骤的Ҏ都封装成抽象的函?SPAN lang=EN-US>,q且提供一个正的序L行这些步?而具体子cd现这些处理各个步骤的抽象Ҏ.
业务逻辑抽象到超c集中化是所谓的”控制反转”了.在传l的cd?一般是由客L来调用类库里的方?而在q里,却是框架控制了用hE?具体的子cd是要求行一个明的契约.在Spring中的MVC框架?jdbc包里.都大量的使用了Template模式.
?SPAN lang=EN-US>Java中的回调函数主要是在实现事g驱动模型的时候用的,但是在Spring里面,回调被赋予了新的意义:通过回调接口(函数)来实现可扩展?如jdbc包的RowcallbackHandler.