|
精华帖 (1) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (8)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2011-05-18
Wanghuidong 写道 Simon.C 写道 没有更通俗易懂的么? 比如自己的如何理解的啊? 同求 这是敝人的理解。 |
| 返回顶楼 | |
|
发表时间：2011-05-18
lxholding 写道 这应该是叫法问题，IOC应该叫“依赖注入”才对 为了纠正这个问题，我已经在本贴写了不少了。 |
| 返回顶楼 | |
|
发表时间：2011-05-18
kakaluyi 写道 控制反转是一种编程思想，可以引申出很多模式，比如一个对象a持有另一个对象b的引用， 1 当对象a更新的时候，通知b对象回调某些方法 （观察者模式） 2 b的状态由a对象来维护（状态模式） 3 控制反转还可以避免代码污染，减少耦合，比如:a和b对象互相持有对方引用. 4 工厂模式（由子类决定创建的具体对象） Factory a=new FactoryImp1() ojbect1=a.create(); Factory b=new FactoryImp2() object2=b.create(); 这样a和b是可以插拔替换的，完全由子类来实现控制创建，也可以说是控制反转。 5 Spring的控制反转，由spring工厂读取xml帮你注入某个类需要的对象 等等等等，和“只和陌生人说话”，“迪米特法则”，“开闭原则”，等作为开发高弹性，高可扩展，高可维护代码的必要法则。 目前，大多数程序员都认为是个原则，不是模式，虽然MF还认为它是模式： 引用 控制反转概念的涉及面十分广泛，有人认为它是一个模式，但是我更倾向于认为它是一个原则（Principle）
|
| 返回顶楼 | |
|
发表时间：2011-05-19
redhat 写道 JE帐号 写道 我一直觉得"控制反转"这个词还是有些抽象.
几乎每次看到对IOC解释都是这样,一大段话,左一个例子,右一个例子,这是IOC,那也是IOC.总觉得这些描述不是属于那种一说出来,大家就恍然大悟的那种话,而是给解释,举例. 这个名字是最好的给这个概念的名字，把对程序的某些控制权交给其他外部程序来控制，即控制反转。 我想你的回答恰恰直接说明了我对"控制反转"的不满. "对程序的某些控制权交给其他外部程序",到底是哪些? 并不是说"控制反转"不对,仅仅是觉得不足够好,没有那种一眼看传的感觉. 要说我,"IOC体现的理念在于,仅仅去使用一个对象,而不需要去关注这个对象如何来的"这句话可能更揭示IOC的本质一些. |
| 返回顶楼 | |
|
发表时间：2011-05-19
JE帐号 写道 redhat 写道 JE帐号 写道 我一直觉得"控制反转"这个词还是有些抽象.
几乎每次看到对IOC解释都是这样,一大段话,左一个例子,右一个例子,这是IOC,那也是IOC.总觉得这些描述不是属于那种一说出来,大家就恍然大悟的那种话,而是给解释,举例. 这个名字是最好的给这个概念的名字，把对程序的某些控制权交给其他外部程序来控制，即控制反转。 我想你的回答恰恰直接说明了我对"控制反转"的不满. "对程序的某些控制权交给其他外部程序",到底是哪些? 并不是说"控制反转"不对,仅仅是觉得不足够好,没有那种一眼看传的感觉. 要说我,"IOC体现的理念在于,仅仅去使用一个对象,而不需要去关注这个对象如何来的"这句话可能更揭示IOC的本质一些. 兄弟，你要你仔细看看题目，你就知道： 引用 "IOC体现的理念在于,仅仅去使用一个对象,而不需要去关注这个对象如何来的" 是个谬误，我专门纠正这个错误来写这篇文档，所以我说你还不太明白IoC的概念来说这个名字有问题。
mf怕大家搞混，准们写了两篇博文说明这个问题，相信写那些书的人和看这些博文的人都看过，但是还是不理解他老人家的意思，IoC的最初出处我都给了地址，你慢慢看吧。 |
| 返回顶楼 | |
|
发表时间：2011-05-19
哗众取宠兼打广告之辈。
|
| 返回顶楼 | |
|
发表时间：2011-05-19
两者没有什么太多区别
DI，依赖倒置，就是一个抽象工厂模式：通过对象的组合，关联一群客户逻辑，以达到逻辑解耦 |
| 返回顶楼 | |
|
发表时间：2011-05-19
smallsnake 写道 两者没有什么太多区别
DI，依赖倒置，就是一个抽象工厂模式：通过对象的组合，关联一群客户逻辑，以达到逻辑解耦 
|
| 返回顶楼 | |
|
发表时间：2011-05-19
redhat 写道 JE帐号 写道 redhat 写道 JE帐号 写道 我一直觉得"控制反转"这个词还是有些抽象.
几乎每次看到对IOC解释都是这样,一大段话,左一个例子,右一个例子,这是IOC,那也是IOC.总觉得这些描述不是属于那种一说出来,大家就恍然大悟的那种话,而是给解释,举例. 这个名字是最好的给这个概念的名字，把对程序的某些控制权交给其他外部程序来控制，即控制反转。 我想你的回答恰恰直接说明了我对"控制反转"的不满. "对程序的某些控制权交给其他外部程序",到底是哪些? 并不是说"控制反转"不对,仅仅是觉得不足够好,没有那种一眼看传的感觉. 要说我,"IOC体现的理念在于,仅仅去使用一个对象,而不需要去关注这个对象如何来的"这句话可能更揭示IOC的本质一些. 兄弟，你要你仔细看看题目，你就知道： 引用 "IOC体现的理念在于,仅仅去使用一个对象,而不需要去关注这个对象如何来的" 是个谬误，我专门纠正这个错误来写这篇文档，所以我说你还不太明白IoC的概念来说这个名字有问题。
mf怕大家搞混，准们写了两篇博文说明这个问题，相信写那些书的人和看这些博文的人都看过，但是还是不理解他老人家的意思，IoC的最初出处我都给了地址，你慢慢看吧。 我看了你的题目了,事实上你blog的文章我很早前就看过了.所以,我不是在反对你的观点,但是问题的关键在于,你要去证明它. 你的观点"IoC != 装配和实例化的反转",我对此很感兴趣,因为就像我说的,我的理解中IoC重点反映的思想就是装配和实例化的反转,现在看到您这样不同的观点,我并不想去反对,而是希望可以看到一些有逻辑性的证明,这些证明可以让我改变观点,对于我个人也是一种进步.但是就我所理解的,我并没有看到这样的证明. 说句实话,MF 05年那篇文章,上来举了两段代码例子,我看来看去,第二段就是比第一段多了实例和装配,倒又是在一定程度上加强了我原先的观点... ... 再补充一下我的理解,IOC概念的出现一定程度上与接口概念类似.由于接口的简洁性,声明性,使得我们可以把注意力转到接口行为上,以及对这种行为能力的使用上,而不去考虑实例化问题.IOC也类似如此,他解放了我们实例化和装配的工作,从而让我们把注意力更多的集中到对象的使用上.不同的是接口是语言层面的支持,而IOC一般是FrameWork层面的支持. 我明白你的意思是说IOC所反映的思想范畴不仅仅包括简单的"装配和实例化的反转",他有更多的内涵.但是从文章我没看到对这一观点更实质的论证. 你不能说句"相信写那些书的人和看这些博文的人都看过，但是还是不理解他老人家的意思"就算了,而是需要去论证它 |
| 返回顶楼 | |
|
发表时间：2011-05-19
JE帐号 写道 redhat 写道 JE帐号 写道 redhat 写道 JE帐号 写道 我一直觉得"控制反转"这个词还是有些抽象.
几乎每次看到对IOC解释都是这样,一大段话,左一个例子,右一个例子,这是IOC,那也是IOC.总觉得这些描述不是属于那种一说出来,大家就恍然大悟的那种话,而是给解释,举例. 这个名字是最好的给这个概念的名字，把对程序的某些控制权交给其他外部程序来控制，即控制反转。 我想你的回答恰恰直接说明了我对"控制反转"的不满. "对程序的某些控制权交给其他外部程序",到底是哪些? 并不是说"控制反转"不对,仅仅是觉得不足够好,没有那种一眼看传的感觉. 要说我,"IOC体现的理念在于,仅仅去使用一个对象,而不需要去关注这个对象如何来的"这句话可能更揭示IOC的本质一些. 兄弟，你要你仔细看看题目，你就知道： 引用 "IOC体现的理念在于,仅仅去使用一个对象,而不需要去关注这个对象如何来的" 是个谬误，我专门纠正这个错误来写这篇文档，所以我说你还不太明白IoC的概念来说这个名字有问题。
mf怕大家搞混，准们写了两篇博文说明这个问题，相信写那些书的人和看这些博文的人都看过，但是还是不理解他老人家的意思，IoC的最初出处我都给了地址，你慢慢看吧。 我看了你的题目了,事实上你blog的文章我很早前就看过了.所以,我不是在反对你的观点,但是问题的关键在于,你要去证明它. 你的观点"IoC != 装配和实例化的反转",我对此很感兴趣,因为就像我说的,我的理解中IoC重点反映的思想就是装配和实例化的反转,现在看到您这样不同的观点,我并不想去反对,而是希望可以看到一些有逻辑性的证明,这些证明可以让我改变观点,对于我个人也是一种进步.但是就我所理解的,我并没有看到这样的证明. 说句实话,MF 05年那篇文章,上来举了两段代码例子,我看来看去,第二段就是比第一段多了实例和装配,倒又是在一定程度上加强了我原先的观点... ... 再补充一下我的理解,IOC概念的出现一定程度上与接口概念类似.由于接口的简洁性,声明性,使得我们可以把注意力转到接口行为上,以及对这种行为能力的使用上,而不去考虑实例化问题.IOC也类似如此,他解放了我们实例化和装配的工作,从而让我们把注意力更多的集中到对象的使用上.不同的是接口是语言层面的支持,而IOC一般是FrameWork层面的支持. 我明白你的意思是说IOC所反映的思想范畴不仅仅包括简单的"装配和实例化的反转",他有更多的内涵.但是从文章我没看到对这一观点更实质的论证. 你不能说句"相信写那些书的人和看这些博文的人都看过，但是还是不理解他老人家的意思"就算了,而是需要去论证它 我不知道为什么需要证明？因为这个是我们目前公认归纳的概念，但是很多人搞不明白这个概念。我这里做的是个传教士的角色，讨论这个概念是什么。 mf在http://martinfowler.com/bliki/InversionOfControl.html专门讲解什么是IoC，很多人不知道IoC出自哪里就开始给大家讲解，结果全解释错另外。 mf在http://martinfowler.com/articles/injection.html一文的Inversion of Control一节，指出 引用 Inversion of control is a common characteristic of frameworks, so saying that these lightweight containers are special because they use inversion of control is like saying my car is special because it has wheels.
引用 The question, is what aspect of control are they inverting? 后面举了一个例子，讲解他开始遇见这个概念是，自己使用到一个框架，这个框架引用 UI framework would contain this main loop ，把这个控制反转到框架了，这样，引用 your program instead provided event handlers for the various fields on the screen 就可以了，不需要写这一个loop来做了。
这里为此写篇文章再次说明，其实要看大家造化了，mf讲解的我自认为很清楚了，但是还有人弄错，我归结为语言的问题（大家很懒，不愿意阅读英文章，喜欢中文，毕竟是习惯），但是现在开来，好像有可能不是这个原因，希望参与讨论者能够仔细阅读完这两篇论文在做讨论，举出什么地方有误。 |
| 返回顶楼 | |
