当前页面: 开发资料首页 → Java 专题 → Matrix java 大讲坛:IoC与Dependnecy Injection
Matrix java 大讲坛:IoC与Dependnecy Injection
摘要: Matrix java 大讲坛:IoC与Dependnecy Injection
Chris-(197750-
专题：IoC 与 Dependnecy Injection
主讲：echoaholic
7月19日-
Chris-(197750-
现在开始.
Chris-(197750-
欢迎我们得echoaholic
10086402-
嘿嘿，好：）
324002862-
[rose]
6947930-
[v]
Chris-(197750-
鼓掌!!
80769563-
先介绍一下!!
Chris-(197750-
开始吧!
Chris-(197750-
大家安静!
80769563-
[;x]
10086402-
那我开始了
10086402-
IoC是Inversion of Control的缩写，是一种设计原则
10086402-
也是很多framework的基本设计思想
10086402-
今天我们从一个简单的例子开始，介绍ioc和framework，然后是ioc在配制管理方面的一个
应用，也就是dependency injection
6947930-
建议主讲用颜色区分
10086402-
可以吗？
Chris-(197750-
echoaholic,用红色吧,主持人绿色,其他人黑色.
20535737-
[rose]
10086402-
sigh
Chris-(197750-
ok,继续
10086402-
好的，现在让我们看一个最简单的frameworks的例子
10086402-
我们都知道framework都是针对某一个具体领域应用的
10086402-
那么最简的一个framework的例子就是template method pattern
10086402-
abstract class PriceService {
- {
- * getAmount(-;
}
-;
-;
}
10086402-
这里给出一个简单的计费服务
10086402-
其中需要两个方法，单价和数量
10086402-
那么针对计费，这一个类就是一个最简单，最丑陋的framework
10086402-
任何具体的计费业务只需扩展这个class然后提供具体的method实现就可以了
10086402-
这里就有IoC
10086402-
method getUnitPrice和getAmount就是IoC Method
80769563-
我有个问题。。。：）
10086402-
也就是反转控制函数
10086402-
说：）
2274459-
讲一个阶段再提问题啦
10086402-
那我继续了：）
20535737-
whats the meaning of IOC
full spelling ?
24889356-
倒～
10086402-
Inversion of Control
80769563-
好吧！我一会儿再说。。
2274459-
2004-07-19 19:51:33- echoaholic(10086402-
IoC是Inversion of Control的缩写，是一种设计原则
2004-07-19 19:51:54- echoaholic(10086402-
也是很多framework的基本设计思想
2004-07-19 19:53:17- echoaholic(10086402-
今天我们从一个简单的例子开始，介绍ioc和framework，然后是ioc在配制管理方面的一个
应用，也就是dependency injection
20535737-
sorry
2274459-
1、一个阶段完了以后再提问题
2、提问题前先看看前面的
13819651-
继续
65267063-
大家安静点，别打断老师的思路。
10086402-
IoC有一个另外的名字，叫好莱坞原则
echoaholic- 20:02:06
也就是don't call us we call u
echoaholic- 20:02:36
我们提供的这两个method，并不直接去调用framework的代码，而是等待framework来调用它
异想者- 20:03:12
echoaholic- 20:03:37
那么在一点上，控制被反转了，也就是method并不自主的控制他的调用点，而是等到外层
的framework来使用它的实现
echoaholic- 20:04:16
这也就是IoC最基本的一个应用，template method pattern
echoaholic- 20:04:50
好，这是一个段落，下面我将把这个framework扩展
wuyu- 20:04:58
当我需要调用的时候，我再来看该找谁，然后再找这个人做事情？
echoaholic- 20:05:03
之前大家可以提一些问题
异想者- 20:05:31
在设计模式中还有什么用到了ioc吗
echoaholic- 20:05:38
to wuyu
这里的意思是说，我们实现的代码是等待别人使用的
孤魂野鬼- 20:06:03
ioc==dependency injection ?
&Limy- 20:06:07
说到ioc,也就是控制反转，我们需要先明晰控制什么？哪些属于控制？有些什么种类？这样，
你在后面讲起来，别人会比较清晰。
echoaholic- 20:06:23
to 异想
template method最明显
echoaholic- 20:06:38
to 孤魂野鬼
ioc != dependency injection
异想者- 20:06:40
谢谢老师
&Limy- 20:06:55
控制有很多种，最简单的就是方法的调用，方法的实现。。。。ioc！=di
crane- 20:07:05
模版模式 和IOC的区别是是么
crane- 20:07:11
是什么
echoaholic- 20:07:22
IoC是一个大的设计原则，注意，是原则，而不是pattern
echoaholic- 20:07:38
to crane，这个后面会说：）
异想者- 20:07:45
依赖倒转就是ioc吗
crane- 20:07:47
：）
~~酉告~~- 20:08:02
dependency injection 只是 ioc 其中一种Pattern
异想者- 20:08:30
我记得在面向对象的原则中提到了它，但当时我不知道是ioc，呵呵
echoaholic- 20:08:39
to &Limy
我的例子是业务反转的例子，后面会扩展，我们会发现，只要有合适的framework，大部分
东西都可以反转
echoaholic- 20:09:09
好，我下面继续了
╃(Chris-- 20:09:17
好的,echoaholic继续
╃(Chris-- 20:09:40
大家安静,等下一个环节结束再发问.echoaholic结束的时候给个提示.
echoaholic- 20:09:49
我们来再看一下这个代码
abstract class PriceService {
- {
- * getAmount(-;
}
-;
-;
}
echoaholic- 20:10:36
由于是最小的framework，我们使用了继承，使得结构有些混乱，那么我们来看一下使
用interface的情况
echoaholic- 20:12:21
final class PriceService {
IUnitPriceProvider upp;
IAmountProvider ap;
- {
- * 阿ap.getAmount(-;
}
}
interface IUnitPriceProvider {
-;
}
interface IAmountProvider {
-;
}
echoaholic- 20:12:57
这个就是一个较为复杂一些的framework，把template method用callback interface代替
echoaholic- 20:14:05
当我们有两个组件 RMIUnitPriceProvider和RMIAmountProvider的时候
echoaholic- 20:14:25
我们可以让priceService去调用这两个组件
echoaholic- 20:14:57
同样这两个组件并不控制自己的调用，而是交给framework去完成
echoaholic- 20:15:17
这样这两个组件也就成了IoC component
echoaholic- 20:15:58
同样，我们可以提供WebServiceUnitPriceProvider和WebServiceAmountProvider
孤魂野鬼- 20:16:44
怎么感觉像EAI，框架负责组装东西，东西的具体实现就靠个个厂家了
echoaholic- 20:17:21
他们同样是IoC Component，那么最为定义业务的PriceService可以选择去使用哪一个具体
的实现，而做为实现的具体组件，并不负责
echoaholic- 20:17:39
最为定义业务-〉作为.....
冰云- 20:18:57
？
echoaholic- 20:19:12
对于PriceService而言，只需要实现IUnitPriceProvider和IAmountProvider的组件，这就
是IoC另外一个名字DIP Dependency Inversion Principle
异想者- 20:20:02
也就是针对抽象编程，是吧，老师
echoaholic- 20:20:10
而做为实现的具体组件，并不负责
这句话有点古怪，大家能意会我就不说了：）
echoaholic- 20:20:47
to 异想
对，这也就是为什么说IoC是一个设计原则而不是pattern的原因
echoaholic- 20:21:21
对组件而言，它是调用控制被反转，对framework而言，依赖倒转
异想者- 20:21:24
这个例子与上一个例子的最大区别就是具体的类变成了抽象的接口，看出来还是不难，您说
得真好
echoaholic- 20:22:19
这就使最初的IoC的形式，在组织一组framework的时候，业务调用被反转
wuyu- 20:22:25
可以提问了吗？（感觉好象是到了一个阶段了）
echoaholic- 20:22:35
可以了：）
wuyu- 20:22:40
对于PriceService的例子，如果采用factory的方法
用一个xml配置文件描述IUnitPriceProvider和具体的实现，比如WebServicesPriceProvider
的关系，class的修改
final class PriceService {
-;
如果从解耦的角度出法，两种方法都可以达到同样的目的。
那么，相对来说，这里使用IOC有什么好处呢？
magicgod- 20:23:22
美国精神，simple & free
echoaholic- 20:23:33
嘿嘿，你这个是dependency management IoC，而我主要说的是业务调用反转
echoaholic- 20:24:18
也就是对于RMIUnitPriceProvider而言，对他的业务调用是反转的：）
echoaholic- 20:24:29
DM IoC还没有说到：）
wuyu- 20:25:11
我的意思是，使用IOC也好，使用factory也好，或是别的方式，都应该有一个目的，如果
是为了解耦的话，看不出来ioc和我举的例子之间有多大的区别啊？而且我要使用Ioc，我
还得加上一个IOC的framework
wuyu- 20:26:13
从现在讲的情况来看，使用IOC能够达到松耦合的目的，除了这个好处以外，IOC区别于别
的解耦手段，还有什么优点呢？
echoaholic- 20:26:16
呵呵，其实你说的IoC是dependency management
&Limy- 20:26:28
对于组件来说，不需要ioc的framework。
echoaholic- 20:26:46
而我说的，是在framework里使用的ioc
冰云- 20:26:57
举个例子来说吧
echoaholic- 20:27:00
比如swing
冰云- 20:27:06
我来说
异想者- 20:27:11
IOC不是一个面对对象的思想吗，它们之间应该是使用和思想的关系吧
冰云- 20:27:15
比如，还是传统的Boy和Girl
nemo- 20:27:25
echoaholic- 20:27:32
业务是kiss
冰云- 20:27:36
Boy和Girl之间有关系，但是并不是Boy可以有个GirlFactory.newInstance
异想者- 20:27:37
&Limy- 20:27:38
还是冰云的那个例子，呵呵。。
冰云- 20:27:50
而是说，可以有Girl给Boy来用
冰云- 20:28:06
换一种情况
冰云- 20:28:14
Boy有Head,Arm, Leg
echoaholic- 20:28:18
你。。。。。你。。。。你把我的例子抢了
冰云- 20:28:23
……
wuyu- 20:28:25
-的？
冰云- 20:28:26
这是我的例子！
异想者- 20:28:29
呵呵
&Limy- 20:28:38
冰云- 20:28:43
boy对head,arm等负责全部生命周期
冰云- 20:28:51
这时候
wuyu- 20:28:55
如果使用factory的话，至少要关心一下谁来当的媒人？
共筑佳话- 20:28:57
继续
冰云- 20:29:04
可以让boy有个factory来创建head,arm,
冰云- 20:29:13
当然，直接new也无不可
echoaholic- 20:29:35
哎~~~~怎么直接讨论到了DM IoC
冰云- 20:29:40
……
冰云- 20:29:46
你继续
异想者- 20:29:52
我想还是让echoaholic继续
共筑佳话- 20:30:05
@寻找
wuyu- 20:30:09
呵呵，等最后估计我就清晰了，先不打岔：）
冰云- 20:30:22
继续继续
异想者- 20:30:23
主持出场呀
孤魂野鬼- 20:30:26
主持人，方丈呢？
echoaholic- 20:30:31
我的意思是业务调用IoC，比如观察者模式
echoaholic- 20:31:04
MessageListener和MessagePublisher
echoaholic- 20:31:45
这个里面的业务就是publisher把message发布到listener
echoaholic- 20:32:11
那么这个里面，listener并不主动去拿message
echoaholic- 20:32:26
而是等待publisher对他调用
echoaholic- 20:32:43
这就是业务调用IoC
echoaholic- 20:33:21
也就是IoC的最初形式，把调用权反转，也是framework里用得最多的形式
&Limy- 20:33:30
其实我觉得还是不要用ioc，用依赖反转比较好，
其实，现在普遍提出的ioc实际上是echo所指的dm ioc
共筑佳话- 20:33:41
异想者- 20:33:53
也就是通过侦听器的使用，使原来客户端调用的方向反向了
echoaholic- 20:34:11
因为ioc是因为dm ioc才有火起来的一个词
echoaholic- 20:34:33
所以一说ioc，大家都觉得是dm ioc
echoaholic- 20:35:33
现在我要澄清的一个问题就是ioc本来是什么
&Limy- 20:35:33
对，所以还是在之前的模式应用里面，用依赖反转比较好。。。而讲到dm ioc在使用ioc来
说，最后总结一下依赖反转就是另一种ioc,这样，你和冰云，就不用争论了：）你继续
冰云- 20:35:58
我没争论阿
&Limy- 20:36:04
所以我一开始就强调一点，什么是ioc里面的c~~~
共筑佳话- 20:36:08
echoaholic- 20:36:13
按照我的理解，ioc就是一种设计原则
echoaholic- 20:36:27
上面是我对这个看法的一个阐述
&Limy- 20:36:55
控制是什么？哪些属于控制，这样大家会比较清晰，好了，你继续，我不打岔了。：）
echoaholic- 20:37:06
如果大家没有疑异，我们可以开始对一些特定ioc的讨论：）
异想者- 20:37:25
我还想问一下
异想者- 20:37:29
AOP是什么
&Limy- 20:37:45
aop在另外一个群里面会讨论到：）
echoaholic- 20:38:03
to &Limy
说得对，我忘记了这一点，上面讲得内容是对业务调用的反转
echoaholic- 20:38:14
应该以开始就说出来：）
&Limy- 20:38:28
呵呵：）所以一开始我就给你提问了：）
&Limy- 20:38:48
其实是在提醒你一下啊 ：）这样就避免刚才对dm的争论了：）
&Limy- 20:39:23
你继续吧~
异想者- 20:39:26
谢谢，我找以了，Aspect Oriented Programming的缩写，意思是面向方面编程
crane- 20:39:36
好拉，继续关注。。。
异想者- 20:39:50
echoaholic- 20:39:54
好，如果没有疑议我就继续了
孤魂野鬼- 20:40:04
概念性的东西。。。。。自己查
javaduke- 20:40:05
继续！
echoaholic- 20:41:02
现在我们来看一下特定领域内的ioc
dependency management IoC
configuration management IoC
lifecycle IoC
等等
crane- 20:41:10
echoaholic- 20:41:25
首先是dm ioc
echoaholic- 20:42:13
也就是从去年5,6月份起很火的pico和spring提供的一种ioc方式
echoaholic- 20:42:53
好，我们看一个例子，还是冰云的那个例子
冰云- 20:43:19
嘿嘿
echoaholic- 20:45:19
class Something {
"icecloud"-;//嘿嘿寒你一下
"????"-;
- {
girl-;
girl-;
girl-;//嘿嘿，再寒你一个
}
}
crane- 20:45:58
冰云- 20:46:07
故意的
异想者- 20:46:08
echoaholic- 20:46:26
对于这个Something Service，在业务上他是IoC的
dragonlan- 20:46:31
^_^
echoaholic- 20:47:09
因为在doSomething里他调用了具体的ioc component，IBoy和IGirl
孤魂野鬼- 20:47:41
怎么感觉ioc无处不在。。。
echoaholic- 20:48:21
同时，这个Something Service局部上也是dip的，因为在doSomething method里没有掉用具
体的实现类，而是使用接口IBoy和IGirl进行的调用
echoaholic- 20:49:09
但是对于整个Something Service而言，它并不是dip的，因为它里面用到new ChineseBoy和
new ChineseGirl
echoaholic- 20:49:49
与具体的实现类发生了依赖，于是就不是dip的了
异想者- 20:50:04
这就是不足的地方啦，呵呵
echoaholic- 20:50:26
那么对于new ChineseBoy和new ChineseGirl这两行代码实际上是什么内容呢？
echoaholic- 20:50:57
这两行代码可以称作dependency assembling code
echoaholic- 20:51:29
因为我们知道，对于一个component而言，在使用它之前，应该保证它是装配完整的
echoaholic- 20:52:05
比如这个something，如果没有boy，那么就不能doSomething，如果没有girl，那么........
echoaholic- 20:52:18
boy就只能yy了
冰云- 20:52:22
抽象了抽象了
异想者- 20:52:23
char- 20:52:25
依赖倒转原则 dip
Dependence Inversion
这些很多跟模式差不多。
echoaholic- 20:52:46
所以一个组件是需要装配的
echoaholic- 20:53:05
现在的情况是，组件自己负责自己的装配
echoaholic- 20:53:33
那么，这里我们可以使用IoC，也就是组件不负责自己的装配
echoaholic- 20:54:02
而把装配的工作交给一个assemble framework
~~酉告~~- 20:54:08
class Something {
IBoy boy = null
IGirl girl =
- {
girl-;
girl-;
girl-;//嘿嘿，再寒你一个
}
}
"icecloud"-;//嘿嘿寒你一下
~~酉告~~- 20:54:21
sorry
异想者- 20:55:14
好了，知道了，只是一个new没什么啦F91672，你真认真
echoaholic- 20:55:40
class Something {
IBoy boy;
IGirl girl;
IBoy boy, IGirl girl- {
this.boy = boy;
this.girl = girl;
}
- {
girl-;
girl-;
girl-;
}
}
孤魂野鬼- 20:56:29
参数化：）
郁也风- 20:56:31
这是type1？
echoaholic- 20:56:36
new ChineseBoy("icecloud"-, new ChineseGirl("???"--;
来完成对组件的装配
~~酉告~~- 20:56:38
constructor
郁也风- 20:56:43
差点没赶上啊：（
echoaholic- 20:56:43
type3
郁也风- 20:56:59
哦，顺序高错了：）
异想者- 20:57:11
~~酉告~~- 20:57:19
new ChineseBoy("icecloud"-, new ChineseGirl("如花"--;//如何。。。。：D
异想者- 20:57:35
F57C7B
echoaholic- 20:57:43
也就是说我们把装配和配置管理，倒转到外面的assemble framework里了
冰云- 20:57:50
crane- 20:57:53
晕
郁也风- 20:58:07
异想者- 20:57:35
F57C7B
echoaholic- 20:58:14
这就是pico和spring的设计原理
农民 - Javen- 20:58:17
请大家少点废话
echoaholic- 20:39:54
好，如果没有疑议我就继续了
孤魂野鬼- 20:40:04
概念性的东西。。。。。自己查
javaduke- 20:40:05
继续！
echoaholic- 20:41:02
现在我们来看一下特定领域内的ioc
dependency management IoC
configuration management IoC
lifecycle IoC
等等
crane- 20:41:10
echoaholic- 20:41:25
首先是dm ioc
echoaholic- 20:42:13
也就是从去年5,6月份起很火的pico和spring提供的一种ioc方式
echoaholic- 20:42:53
好，我们看一个例子，还是冰云的那个例子
冰云- 20:43:19
嘿嘿
echoaholic- 20:45:19
class Something {
"icecloud"-;//嘿嘿寒你一下
"????"-;
- {
girl-;
girl-;
girl-;//嘿嘿，再寒你一个
}
}
crane- 20:45:58
冰云- 20:46:07
故意的
异想者- 20:46:08
echoaholic- 20:46:26
对于这个Something Service，在业务上他是IoC的
dragonlan- 20:46:31
^_^
echoaholic- 20:47:09
因为在doSomething里他调用了具体的ioc component，IBoy和IGirl
孤魂野鬼- 20:47:41
怎么感觉ioc无处不在。。。
echoaholic- 20:48:21
同时，这个Something Service局部上也是dip的，因为在doSomething method里没有掉用具
体的实现类，而是使用接口IBoy和IGirl进行的调用
echoaholic- 20:49:09
但是对于整个Something Service而言，它并不是dip的，因为它里面用到new ChineseBoy和
new ChineseGirl
echoaholic- 20:49:49
与具体的实现类发生了依赖，于是就不是dip的了
异想者- 20:50:04
这就是不足的地方啦，呵呵
echoaholic- 20:50:26
那么对于new ChineseBoy和new ChineseGirl这两行代码实际上是什么内容呢？
echoaholic- 20:50:57
这两行代码可以称作dependency assembling code
echoaholic- 20:51:29
因为我们知道，对于一个component而言，在使用它之前，应该保证它是装配完整的
echoaholic- 20:52:05
比如这个something，如果没有boy，那么就不能doSomething，如果没有girl，那么........
echoaholic- 20:52:18
boy就只能yy了
冰云- 20:52:22
抽象了抽象了
异想者- 20:52:23
char- 20:52:25
依赖倒转原则 dip
Dependence Inversion
这些很多跟模式差不多。
echoaholic- 20:52:46
所以一个组件是需要装配的
echoaholic- 20:53:05
现在的情况是，组件自己负责自己的装配
echoaholic- 20:53:33
那么，这里我们可以使用IoC，也就是组件不负责自己的装配
echoaholic- 20:54:02
而把装配的工作交给一个assemble framework
~~酉告~~- 20:54:08
class Something {
IBoy boy = null
IGirl girl =
- {
girl-;
girl-;
girl-;//嘿嘿，再寒你一个
}
}
"icecloud"-;//嘿嘿寒你一下
~~酉告~~- 20:54:21
sorry
异想者- 20:55:14
好了，知道了，只是一个new没什么啦F91672，你真认真
echoaholic- 20:55:40
class Something {
IBoy boy;
IGirl girl;
IBoy boy, IGirl girl- {
this.boy = boy;
this.girl = girl;
}
- {
girl-;
girl-;
girl-;
}
}
孤魂野鬼- 20:56:29
参数化：）
郁也风- 20:56:31
这是type1？
echoaholic- 20:56:36
new ChineseBoy("icecloud"-, new ChineseGirl("???"--;
来完成对组件的装配
~~酉告~~- 20:56:38
constructor
郁也风- 20:56:43
差点没赶上啊：（
echoaholic- 20:56:43
type3
郁也风- 20:56:59
哦，顺序高错了：）
异想者- 20:57:11
~~酉告~~- 20:57:19
new ChineseBoy("icecloud"-, new ChineseGirl("如花"--;//如何。。。。：D
异想者- 20:57:35
F57C7B
echoaholic- 20:57:43
也就是说我们把装配和配置管理，倒转到外面的assemble framework里了
冰云- 20:57:50
crane- 20:57:53
晕
郁也风- 20:58:07
异想者- 20:57:35
F57C7B
echoaholic- 20:58:14
这就是pico和spring的设计原理
农民 - Javen- 20:58:17
请大家少点废话
echoaholic- 20:58:41
实际上，pico和spring就是那个assemble framework
echoaholic- 20:59:13
echoaholic- 20:59:13
他的业务就是装配，他反转的就是装配控制
echoaholic- 21:00:14
当然，没有dm IoC container之前，我们使用Factory以及其它的创建模式，目的也是一样的
echoaholic- 21:00:49
把创建一致组件的工作的交给factory
异想者- 21:00:49
实际上，pico和spring就是那个assemble framework
可以说个例子吗
echoaholic- 21:01:05
例子后面就有了：）
异想者- 21:01:10
echoaholic- 21:01:55
对于一个具体的factory而言，我们可以认为它就是一个针对特定组件的最小的assemble framework
echoaholic- 21:02:26
那么使用factory和pico等container有什么区别呢？
echoaholic- 21:02:58
factory是针对特定的组件的
echoaholic- 21:03:26
而pico，spring等则定义了一套通用的方法
echoaholic- 21:03:36
也就是dependency injection
echoaholic- 21:04:24
因此我们可以认为，depedency injection是IoC在dependency manage或assemble领域内的
一个特定应用pattern
异想者- 21:04:53
echoaholic- 21:05:15
下面我们来看一下具体的dependency injection这个模式，之前大家可以提问
孤魂野鬼- 21:06:09
刚才有人说：di是ioc的一种？这样理解ok？
孤魂野鬼- 21:06:20
ioc是个原则，di是个模式
echoaholic- 21:06:20
ok
echoaholic- 21:06:35
但不太严禁
echoaholic- 21:07:22
di是模式，它的思想是ioc,template method也是pattern，它的思想还是ioc
echoaholic- 21:08:18
不过是不同领域的ioc而已
异想者- 21:08:37
它们的思想
~~酉告~~- 21:08:45
type1:interface injection type2:setter injection type3:constructor injection
type1比较难懂。通过实现特定接口完成“依赖注入”？
异想者- 21:08:56
归根到底都是关注点分离
echoaholic- 21:09:04
这个马上就会说到
echoaholic- 21:09:15
异想者- 21:08:56
归根到底都是关注点分离
以及职责单一
异想者- 21:09:25
谢谢
共筑佳话- 21:09:41
职责单一
echoaholic- 21:10:12
没问题我们继续了：）
javaduke- 21:11:06
echoaholic- 21:11:16
di有这样几个类型
~~酉告~~- 21:08:45
type1:interface injection type2:setter injection type3:constructor injection
echoaholic- 21:11:27
我们先看interface injection
echoaholic- 21:11:35
也就是type1
echoaholic- 21:11:51
其实type1是dm ioc最自然的发展
echoaholic- 21:12:54
我们开始的时候说了，ioc最初形式，是业务调用控制反转
echoaholic- 21:13:48
type1 dm ioc是把dependency injection作为一个业务来看待的
echoaholic- 21:14:04
比如还是例子
echoaholic- 21:15:29
在interface injection里，需要这样一个接口
interface IBoyGirlAware {
IBoy boy-;
IGirl girl-;
}
echoaholic- 21:16:01
把介绍男孩和介绍女孩作为业务的一部分来看待
echoaholic- 21:17:30
然后Something implements IBoyGirlAware
new ChineseBoy("icecloud"--;
new ChineseGirl("???"--;
echoaholic- 21:18:02
具体的装配代码就是这样的，完全按照dip，来做
echoaholic- 21:18:26
也就是业务调用反转在dm领域的自然延展
echoaholic- 21:19:37
典型的框架代表是avalon
echoaholic- 21:21:12
虽然type1在感念延展上很自然，但是这也带来了问题，对于业务interface，这样没有什么
问题，但是如果是对于基础服务，比如log等等，需要实现自己的Loggable interface
echoaholic- 21:21:44
那么在移植的时候，这些技术性接口就会带来很大的问题
echoaholic- 21:22:47
因为使用什么样的log是组件的自己的事，是实现级别的事，一旦暴露在接口上，就是接口行为了
echoaholic- 21:22:55
对外性质的定义
echoaholic- 21:23:18
无论从设计思路和移植上都存在较大的困难
echoaholic- 21:23:27
哎~~~病句
echoaholic- 21:23:36
设计思路存在很大问题
echoaholic- 21:24:37
但如果你的组件要injection的dependency都是业务级的，那么使用interface injection也
是不错的方案
echoaholic- 21:26:06
avalon本意是设计一个纯cbd framework,在cbd里，component都是业务上的，不会实现任何
技术接口，那么avalon使用这种方式也就是可以理解甚至是指得称道的了
农民 - Javen- 21:26:10
现在好像说的是： 像你说的如 log exception 等公共服务，比如合适用 AOP
echoaholic- 21:26:22
对
echoaholic- 21:27:39
然后avalon并没有在container层对技术做一个很好的实现，于是他的组件不得以还是要实现
技术接口，avalon也试图规范这些接口，但最终的结果是把组件绑在了avalon上，给移植带
来了更大的困难
echoaholic- 21:28:18
所以，一般而言会认识avalon的type1比较失败，同时不够轻量化，属于次轻量级dm ioc container
echoaholic- 21:28:42
实际type1还是不错的，只不过avalon的实现有问题
crane- 21:28:59
异想者- 21:29:05
提问
echoaholic- 21:29:36
好，正是一个段落
&Limy- 21:29:43
刚才出去了一下，讲到哪里了？ioc type?
echoaholic- 21:29:52
异想者- 21:30:02
我推测是不是因为它在接口的组装时没有从容器配置中读取
echoaholic- 21:30:09
&Limy给你两分钟review
echoaholic- 21:30:40
to 异想者
这个还是读取了的
&Limy- 21:30:54
在讲type 1 2 3 ...martin对其作了从新定义
异想者- 21:30:58
如果用工厂方法，通过读取配置信息的方法，那为什么还是有问题呢
echoaholic- 21:31:45
嘿嘿，工厂是特殊的dm ioc容器，dm ioc容器是一般化的工厂
echoaholic- 21:32:06
&Limy- 21:30:54
在讲type 1 2 3 ...martin对其作了从新定义
interface injection太长，type1短.......
农民 - Javen- 21:32:19
avalon 的问题所在是不是：他的公共服务也是用的 interface injection 。那时还没有 AOP
而现在 JBoss 好像大量用了 AOP ，主要是不是也是公共服务上？
echoaholic- 21:32:59
对，在服务端使用aop增强技术关注，是实现容器的好办法
magicgod- 21:33:03
avalon的问题一在太重，二在较封闭不自然
&Limy- 21:33:07
可是interface injection说出来就让人知道他是如何注入的，而不想type3那样。。。挺难分。
异想者- 21:33:17
噢，也就是这样的话，它所有的插件都必须实现工厂所要求的一个特殊的接口
echoaholic- 21:33:33
对，avalon就是这个思路
异想者- 21:33:48
谢谢
echoaholic- 21:34:17
to magicgod
我倒是认为从设计上讲，avalon最自然，最与实现语言无关
echoaholic- 21:34:29
因为si和ci需要反射
magicgod- 21:34:43
实现自有接口就有点不自然了
echoaholic- 21:34:51
其中si尤其是参照javabean
孤魂野鬼- 21:35:08
si ,ci?
magicgod- 21:35:23
尽量把烦恼让给框架之类
&Limy- 21:35:27
就是两种注入
echoaholic- 21:35:27
magicgod- 21:34:43
实现自有接口就有点不自然了
所以说，如果是业务接口就自然，技术接口就不自然
~~酉告~~- 21:35:30
setter injection
constructor injection
&Limy- 21:35:54
所以说，如果是业务接口就自然，技术接口就不自然
统一
magicgod- 21:36:00
应该给业务实现者提供一个非常好的氛围
&Limy- 21:36:00
所以说，如果是业务接口就自然，技术接口就不自然
同意
异想者- 21:36:14
echoaholic- 21:36:27
更多使用容器技术-，就很好
&Limy- 21:36:28
不应该依赖于单一的注入方法，各取所长。
异想者- 21:37:04
你认为如果不换体系架构，可以改吗
异想者- 21:37:45
echoaholic- 21:36:27
更多使用容器技术-，就很好
提问：你认为如果不换体系架构，可以改吗
echoaholic- 21:37:53
可以
异想者- 21:38:05
~~酉告~~- 21:38:08
因为层层代理和反射的关系，现在的程序越来越难懂了。。。。。
echoaholic- 21:38:10
因为avalon的容器实现是透明的
echoaholic- 21:38:36
组件交互是通过context也就是naming service实现的
echoaholic- 21:38:57
于是他的架构延展性就很强
echoaholic- 21:39:11
给了他很多使用容器的机会
&Limy- 21:39:21
因为层层代理和反射的关系，现在的程序越来越难懂了。。。。。
代理与反射是框架替自己做的，做业务实现大部分不需要自己使用它，除非你自己写个framework
echoaholic- 21:39:48
但是问题是，如果更多的使用容器，那么avalon就会越来越重
echoaholic- 21:40:18
当然，ioc contaienr也不一定必须是lightweight container
echoaholic- 21:40:31
不过pico和spring都非常轻
异想者- 21:40:43
你是说它可以使用抽象工厂方法来解决吗
~~酉告~~- 21:40:44
现在很多情况上是framework上再加另一个framework。。。。。。
echoaholic- 21:41:02
给大家的印象就是dm ioc container都很轻，也都该很轻
孤魂野鬼- 21:41:25
轻装上阵，我喜欢
异想者- 21:41:25
异想者- 21:40:43
你是说它可以使用抽象工厂方法来解决吗
echoaholic- 21:41:51
嘿嘿，对于给定组件群可以
echoaholic- 21:41:58
但不够通用
echoaholic- 21:42:34
dm ioc container给出的是一个通用的方案
异想者- 21:42:43
呵呵，谢谢，是我不了解avalon，我不问了，您继续吧
&Limy- 21:43:01
ioc之所以很受欢迎，是在于它能够使得container变轻，比如spring,nanning...所以，
ioc需要轻啊。：）
echoaholic- 21:43:44
嘿嘿，如果是完全cbd,就很难很轻，只能比较轻
异想者- 21:44:03
呵呵， 时间有限
echoaholic- 21:44:07
比如eclipse runtime那个container
异想者- 21:44:26
eclipse runtime那个container
农民 - Javen- 21:44:37
cbd 具体指什么？
echoaholic- 21:44:44
嘿嘿，好，下面是setter injection，也就是以前的type2
echoaholic- 21:44:53
component-based development
异想者- 21:45:07
对不起，eclipse runtime那个container，请一定说说，什么时候都可以
echoaholic- 21:45:19
好，下次：）
异想者- 21:45:29
，好的
农民 - Javen- 21:45:38
欢迎 echo 作为下一个专题吧！ eclipse 有太多可以研究的东西！
echoaholic- 21:45:52
setter injection是spring比较推荐的一种方案
异想者- 21:46:02
，好，明天，呵呵
echoaholic- 21:46:25
spring的思路是以javaBean作为最小的组件实现
echoaholic- 21:46:34
异想者- 21:46:02
，好，明天，呵呵
异想者- 21:46:42
6BBE90
异想者- 21:46:50
我知道你有事的
echoaholic- 21:47:01
于是，在整个spring的设计里都比较强调bean
echoaholic- 21:47:31
bean对外有property，event，method
echoaholic- 21:48:01
dependency实际上就是oo里的关联（或者聚合，这个可能更贴切）
echoaholic- 21:48:21
于是property自然是最好的表现关联的场所
echoaholic- 21:48:59
于是spring选择了property作为dependency injection的场所
echoaholic- 21:49:41
自然也就是property的asseccer method里的setter方法
echoaholic- 21:50:00
说一句题外的，这个思路发展一下就使field injection
异想者- 21:50:31
field injection不了解
异想者- 21:50:39
~~酉告~~- 21:50:47
有区别吗？
echoaholic- 21:51:08
www.cnblogs.com/raimundo
echoaholic- 21:51:26
嘿嘿，借机推销一下Blog：）
10086402-
有一篇关于field injection的，我们继续看setter
10086402-
那么么个例子就变成了
class Something {
IBoy boy-{}
IGirl girl-{}
}
具体实现不写了
10086402-
然后可以在spring里指定，Something的boy property和girl property为一些具体的component
10086402-
冰云，补充一个xml吧
10086402-
我都好久不用spring了
6947930-
IBoy boy-{}
这个方法有实现业务的程序员实现么
10086402-
对
6947930-
这个方法由实现业务的程序员实现么
10086402-
就像一个一般的javabean一样
6947930-
哦，那会很乱套的
10086402-
对
10086402-
不会
6947930-
有例子么
324002862-
呵呵
10086402-
我还是给完全吧
324002862-
组件由外部提供，组装的步骤由内部实现，不会乱的
10086402-
class Something {
IBoy boy;
IGirl girl;
IBoy boy- {
this.boy = boy;
}
IGirl girl-{
this.girl = girl;
}
- {
}
}
echoaholic- 21:57:13
BeanFactory-来装配
echoaholic- 21:57:21
然后我们这么用
crane- 21:58:08
业务程序员写这行代码么 this.girl = girl;
echoaholic- 21:58:19
-;
。。。。
"Something"-;
-;
异想者- 21:58:41
但这样，组件还是要符合接口的要求，还是特定的类呀
echoaholic- 21:58:45
从factory get出来的时候已经装配好了
crane- 21:58:56
哦
echoaholic- 21:59:01
crane- 21:58:08
业务程序员写这行代码么 this.girl = girl;
可以用ide声称
echoaholic- 21:59:35
异想者- 21:58:41
但这样，组件还是要符合接口的要求，还是特定的类呀
dm ioc container只负责装配，不负责业务，刚才说的特定接口依赖
echoaholic- 21:59:52
是与装配有关的接口
echoaholic- 22:00:10
interface IBoyGirlAware {
IBoy boy-;
IGirl girl-;
}
异想者- 22:00:16
明白了，谢谢
crane- 22:00:18
那就麻烦了， 业务程序员写这行代码（this.girl = girl;）
时，回乱写的
crane- 22:00:24
会乱写的
echoaholic- 22:00:39
不会，因为是按javaBean的方法来写
crane- 22:00:54
没有约束，这个约束不是通过编译器来检查的
异想者- 22:01:01
但用ide是如何声称装配方法的呢
echoaholic- 22:01:29
没关系，spring把setter的具体实现看作是和业务有关的
crane- 22:01:37
方便的时候再请教
echoaholic- 22:02:05
也就是我只负责把你需要的组件送到指定的setter方法里，至于怎么处置，是你的事
echoaholic- 22:02:47
因为送出指定component是dm的业务，而具体你的bean怎么保管这个component，
是你的业务设计
冰云- 22:03:14
http://gabriel.jarchitect.org/spring/BeanTutorial1.html
异想者- 22:03:16
我在想
冰云- 22:03:32
spring入门
异想者- 22:03:42
谢谢
&Limy- 22:03:56
我又回来了：）
冰云- 22:04:26
http://www.picocontainer.org/One+minute+description
冰云- 22:04:29
pico入门
echoaholic- 22:04:40
我们不用深究spring了，这里面的思路就是，component定义一种声明依赖的方式，然后
dm ioc container负责把依赖送到
&Limy- 22:04:42
谁贴一下刚才讨论的信息？
echoaholic- 22:05:09
spring定义的依赖声明方式就是使用bean property
echoaholic- 22:05:25
然后用setter送入
农民 - Javen- 22:05:26
会后我会整理好记录，并发布到网站的。
&Limy- 22:05:39
ok:)
echoaholic- 22:05:46
这便称作setter injection
异想者- 22:06:06
你继续说吧，我一下子还想不明白，呵呵
异想者- 22:06:14
别在意
echoaholic- 22:06:24
我们可以看出，si和interface injection是有思路上的差异的
echoaholic- 22:07:28
avalon-是把注入当作业务接口的扩展，而spring等则是采用声明依赖的方式
echoaholic- 22:07:59
constructor injection就是在constructor里声明依赖
echoaholic- 22:08:20
也就是pico推荐的方式
echoaholic- 22:08:43
同样那个例子
echoaholic- 22:09:29
class Something {
IBoy boy;
IGirl girl;
IBoy boy, IGirl girl- {
}
- {
.......
}
}
echoaholic- 22:09:53
使用construtor里parameter声明他的依赖
echoaholic- 22:10:52
在pico里可以这样使用
echoaholic- 22:11:42
Something.class-;
IBoy.class, new ChineseBoy("icecloud"--;
IGirl.class, new ChineseGirl("???"--;
echoaholic- 22:12:30
Something.class-;
-;
echoaholic- 22:13:11
"icecloud"-; girl
"???"-;
echoaholic- 22:14:14
思路和spring其实是一样的，不过声明依赖的方式不同罢了，至于其它优劣的比较已经有
太多的讨论了，我就不重复了
echoaholic- 22:14:24
ci就这样，大家有什么问题
异想者- 22:15:11
呵呵，我明白我的上一个问题了
echoaholic- 22:15:39
嘿嘿：）
异想者- 22:15:46
type1中由于使用了自己声明组件组装的方法
echoaholic- 22:16:01
从这里一印证就很容易明白了：）
异想者- 22:16:11
所以外界对于它的输入的扩展是不利的
异想者- 22:16:33
type2由于使用了外界组件声明的方法
echoaholic- 22:16:47
to 异想
u got the point
异想者- 22:16:56
加上不同的javabean可以有不同的业务方法，所以...
异想者- 22:17:11
好了，我不说了，暂时没有什么问题
异想者- 22:17:56
如果有时间，我想听听eclipse的容器，它是使用的哪一种呀
异想者- 22:18:13
其它的人不知愿意不愿意
echoaholic- 22:18:29
那么dependency injection就ok了
下面很好理解，configuration management IoC我们可以使用类似的configuration injection
echoaholic- 22:18:46
eclipse就不是dm ioc cotainer。。。。
echoaholic- 22:18:55
是component container
echoaholic- 22:19:03
更复杂了
农民 - Javen- 22:19:24
好了，非常非常非常感谢 echo 的努力。 二个半小时了，也累坏了吧！
今天就到这里！
异想者- 22:19:35
郁也风- 22:19:38
呵呵，鼓掌
冰云- 22:19:43
…… 好像还差一些
crane- 22:19:44
冰云- 22:19:52
再开个 IOC（下）
泥娃娃- 22:19:52
受益不少,
非常感谢
echoaholic- 22:19:57
dm ioc和cm ioc之所以简单
郁也风- 22:19:57
虽说不太明白，不过只好自己努力了；）
雪儿飞飞- 22:20:02
╃(Chris-- 22:20:04
呵呵,非常感谢
农民 - Javen- 22:20:05
有机会以后再多多交流
异想者- 22:20:05
谢谢，如果可以的话，支持
crane- 22:20:14
郁也风- 22:19:57
虽说不太明白，不过只好自己努力了；）
我也是
异想者- 22:20:24
echoaholic- 22:19:57
dm ioc和cm ioc之所以简单
异想者- 22:20:39
echoaholic还没有说完，大家别说话
echoaholic- 22:21:09
因为他们的业务简单，只反转dm和cm，我们可以使用ioc的思想，翻转我们想反转的一切，
去解耦：）
echoaholic- 22:21:21
结论：）
echoaholic- 22:21:37
还有就是ioc != dependency injection
echoaholic- 22:21:45
就没了：）
crane- 22:22:10
支持 IOC（下） 然后我先预习去
异想者- 22:22:14
,真的完了吗，好期待，好享受
echoaholic- 22:22:41
累死我了，歇会先：）
雪儿飞飞- 22:22:51
讲得非常好，我一点都不懂的，也有所了解
异想者- 22:22:51
crane- 22:22:52
谢谢 echoaholic
农民 - Javen- 22:23:10
是啊。 今天学习到不少的东西。 虽然我还没有太懂，但至少思想上有些指导了。
农民 - Javen- 22:23:43
还是来点酒吧。 酒是比较解累的。
农民 - Javen- 22:24:00
要不来红牛：
困了累了喝红牛！！！
echoaholic- 22:24:58
农民 - Javen- 22:24:00
要不来红牛：
困了累了喝红牛！！！
太甜......
echoaholic: 模式和架构高手.
访问www.matrix.org.cn 留意最新的讲座消息
Java, java, J2SE, j2se, J2EE, j2ee, J2ME, j2me, ejb, ejb3, JBOSS, jboss, spring, hibernate, jdo, struts, webwork, ajax, AJAX, mysql, MySQL, Oracle, Weblogic, Websphere, scjp, scjd↑返回目录
前一篇: 技术原型法：软件技术难点不等于软件目标--从技术交流看软件实现思路
后一篇: What"s MDA?