疯子在思考之IOC

控制反转 英语：Inversion of control，缩写为IoC
我想很多同学都会思考过这样的一个问题，控制反转，什么地方反转了，是不是翻译的不对？
这里插一句
当年马云借着盖茨的嘴说：“互联网会改变世界。”其实是他自己说的，因为那时侯没有人认识马云，如果我说是翻译错误，大家肯定拍砖说我没理解。
大家对spring都用了很多年，有喜欢看书的同学一定会看到过spring 技术内幕，非常棒的一本书，没看的看过这篇博客之后记得买一本。
细心的同学可能会记得这样一句话

早在2004年，Martin Fowler就提出了“哪些方面的控制被反转了？”这个问题。他总结出是依赖对象的获得被反转了。基于这个结论，他为控制反转创造了一个更好的名字：依赖注入。--摘自维基百科
其实他真的翻译的不够友好，所以后来才有了依赖注入（Dependency Injection，简称DI）。其实他们说的是一个意思。


bean的历史及工场模式:
最原始的bean是直接new出来的，后来出来了工场，把所有的bean放到工厂里统一生产，但还是写new，只不过这个new放在一个方法里了。再后来就是依赖注入帮了我们大忙，我们看不见new了。其实spring ioc就是一个大工厂 BeanFactory

有好多同学说过接口有什么用？我不用接口一样写代码，我不用spring一样new.

OOP的三个特性是封闭继承和多态，三个特性，继承和多态就占了两个,学java的人都应该看think in java。里面也强调了代码复用的三个方式是组合，继承和代理。这六点其实非常重要。
think in java引入过一个名词叫做"客户端程序员",其实我们所有应用框架的人都是客户端程序员，那么框架的设计的要想到可扩展性和代码的复用性以及兼容性。想想spring就很容易理解，这些都需要接口。

  有接口就会有多态，有多态就需要修改new后边的代码，如果这些写到代码里，很多的话，重构就会带来问题。这是第一点；其二通过ioc可以实现bean的统一管理，很方便，对bean的依赖关系一目了然，很容易把握全局，利于分析。所以ioc确实是非常有用的，是很棒的思想。


从字面上理解，两个词，一个是依赖一个是注入。
谭浩强说过这样一句话：“程序=算法+数据结构”
所以分析Ioc我们从数据结构入手。它实际上有一个beanDefinition 的定义类,要实现注入首先我们要知道某个bean 的class及这个class的依赖关系，然后通过递归进行实例化并注入。
大家都知道spring的bean有两种形式，singleton及prototype
其实了解这些思想之后我们很容易想到其实就是通过对xml的解释来实生成bean的过程，如果是singleton那么我们直接缓存bean.如果是protoype我们缓存class.
所以归结起来最核心的功能就是对xml的解析及递归调用的算法，感兴趣的同学可以参考我框架中的ioc 包，里边有具体实现。

评论

40 楼 downpour 2013-07-23  

我已经说了，你已经误入歧途，只可惜你戾气太重，始终不能自拔。

你的观点来自于维基百科。可惜的是，维基百科也是普通人编辑的，谁告诉你维基百科的观点就是正确的？你要引用一个人的观点，你就必须用他自己说的话来证明这个观点是正确的，你总不至于引用一个维基百科的东西，陈述了一个和他的观点截然不同的东西，然后告诉大家这个观点是正确的吧。

我已经列了martin的原文给你了，仔细读原文，相信你还是能够理解他到底在说什么的。由于你过于纠结于其他的问题，而忽略了martin到底在描述IoC的时候说了些什么。从你最新的回复中可以看到，你依旧把两个截然不同的概念混为一谈，可见你根本没有细读并思考martin的文章。

我看了一些你其他的文章，对Spring的理解在我看来其实也有问题。不过那个你可以有自己的观点，因为这并不影响对一个早已有定论的概念（例如IoC）的阐述和传播。

39 楼 zh_harry 2013-07-23  

我现在回过头来看五年前看过的书，有时侯以为被骗钱了，绕来绕去就那么几个意思，尤其是国内的书。

我们回归到问题本源。
其实他到底叫控制反转还是叫依赖注入。我是这样理解，控制反转是解决问题的思想，依赖注入是实现方法,没有必要纠结在概念上。我们要做的无非就是易于维护和方便扩展。

38 楼 zh_harry 2013-07-23  

mike.liu 写道

downpour 写道

zh_harry 写道

downpour 写道

从一开始，理解就错了。所以我从来都不主张通过博客来表达所谓的心得体会，因为不正确的观点会通过博客散播开来造成对别人的误导。

你说说什么地方是错的呢？我错没关系，我可以接受，我最不能接受的是不说出错在哪？你用意何在呢？

问题是我有什么义务告诉你错在哪里？告诉你错了就已经是在提醒你注意了，要是你找不到你错在哪里，那么显然你就不该写博客谈所谓的心得体会。

写博客你可以阐述观点，但是必须要有引证来证明。你写一堆心得体会，但是没有东西证明你这体会是正确的，那显然是有问题的。我也写博客，但是我很少写心得体会，一般只会引用别人的观点，然后加以阐述。如果阐述自己的观点，一定找出旁证来说明。

我费力帮你搜了martin fowler的原文：http://martinfowler.com/bliki/InversionOfControl.html

引用

There's a big difference now in the flow of control between these programs - in particular the control of when the process_name and process_quest methods are called. In the command line form I control when these methods are called, but in the window example I don't. Instead I hand control over to the windowing system (with the Tk.mainloop command). It then decides when to call my methods, based on the bindings I made when creating the form. The control is inverted - it calls me rather me calling the framework.

到底什么是控制反转？你的原文中的阐述：依赖对象的获得被反转。你看看和martin说的一样么？IoC和DI是完全2种不同的概念，这也是martin另外撰文阐述过：http://www.martinfowler.com/articles/injection.html。但是在你的博客中，却把2个东西说成是一个意思。

年轻人，态度决定一切。做技术如果不够严谨，光会思考也是不够的。少一分戾气，多一分执着。

呵呵，看得出楼主也算是潜心于技术的了。

至于误导不误导，我是这样理解的：欧阳锋逆练九阴真经，不是最终天下第一了？软件设计领域，如果有宇宙真理，那早就该没这门学问了。按照写《Unix程序设计艺术》作者（这个作者该绝对牛B了吧）的观点，Windows操作系统应该就是死无葬身之地的，因为它违背的“正确”的原则的地方太多太多了。但如今Windows还算活得很好。

目前大多数的程序设计原则、理论，其中一个重要目的，还是预防普通的或差劲的程序员的破坏力，也就是说向着工业化生产软件的方向努力。但是目前为止，软件设计或多或少还是一门技艺，而非技术。技艺没有绝对的标准，而技术有。

做这一行的，勤于思考，是最重要的。努力去误导别人，或被被人误导，都是必须经历的。

楼主的思考，对我还是有启发的。不过，一些概念的精确性的确需要加强。总之，我更看重思考过程本身。

概念的精确性需要加强我承认，是需要学习和加强，但至少我有寻根问底的意识，现在的好多年轻都还是很浮澡的。我不是圣人，我所强调的是思考的过程，其他的只要我们的目的达到了，真正理解了，我认为要比绕来绕去要强得多，关于思维的科学我觉得易经很棒，虽然我只是理解了一点皮毛。它让人的思考从无到有。

37 楼 mike.liu 2013-07-23  

downpour 写道

zh_harry 写道

downpour 写道

从一开始，理解就错了。所以我从来都不主张通过博客来表达所谓的心得体会，因为不正确的观点会通过博客散播开来造成对别人的误导。

你说说什么地方是错的呢？我错没关系，我可以接受，我最不能接受的是不说出错在哪？你用意何在呢？

问题是我有什么义务告诉你错在哪里？告诉你错了就已经是在提醒你注意了，要是你找不到你错在哪里，那么显然你就不该写博客谈所谓的心得体会。

写博客你可以阐述观点，但是必须要有引证来证明。你写一堆心得体会，但是没有东西证明你这体会是正确的，那显然是有问题的。我也写博客，但是我很少写心得体会，一般只会引用别人的观点，然后加以阐述。如果阐述自己的观点，一定找出旁证来说明。

我费力帮你搜了martin fowler的原文：http://martinfowler.com/bliki/InversionOfControl.html

引用

There's a big difference now in the flow of control between these programs - in particular the control of when the process_name and process_quest methods are called. In the command line form I control when these methods are called, but in the window example I don't. Instead I hand control over to the windowing system (with the Tk.mainloop command). It then decides when to call my methods, based on the bindings I made when creating the form. The control is inverted - it calls me rather me calling the framework.

到底什么是控制反转？你的原文中的阐述：依赖对象的获得被反转。你看看和martin说的一样么？IoC和DI是完全2种不同的概念，这也是martin另外撰文阐述过：http://www.martinfowler.com/articles/injection.html。但是在你的博客中，却把2个东西说成是一个意思。

年轻人，态度决定一切。做技术如果不够严谨，光会思考也是不够的。少一分戾气，多一分执着。

呵呵，看得出楼主也算是潜心于技术的了。

至于误导不误导，我是这样理解的：欧阳锋逆练九阴真经，不是最终天下第一了？软件设计领域，如果有宇宙真理，那早就该没这门学问了。按照写《Unix程序设计艺术》作者（这个作者该绝对牛B了吧）的观点，Windows操作系统应该就是死无葬身之地的，因为它违背的“正确”的原则的地方太多太多了。但如今Windows还算活得很好。

目前大多数的程序设计原则、理论，其中一个重要目的，还是预防普通的或差劲的程序员的破坏力，也就是说向着工业化生产软件的方向努力。但是目前为止，软件设计或多或少还是一门技艺，而非技术。技艺没有绝对的标准，而技术有。

做这一行的，勤于思考，是最重要的。努力去误导别人，或被被人误导，都是必须经历的。

楼主的思考，对我还是有启发的。不过，一些概念的精确性的确需要加强。总之，我更看重思考过程本身。

36 楼 zh_harry 2013-07-23  

早在2004年，Martin Fowler就提出了“哪些方面的控制被反转了？”这个问题。他总结出是依赖对象的获得被反转了。基于这个结论，他为控制反转创造了一个更好的名字：依赖注入。--

downpour 写道

zh_harry 写道

downpour 写道

从一开始，理解就错了。所以我从来都不主张通过博客来表达所谓的心得体会，因为不正确的观点会通过博客散播开来造成对别人的误导。

你说说什么地方是错的呢？我错没关系，我可以接受，我最不能接受的是不说出错在哪？你用意何在呢？

问题是我有什么义务告诉你错在哪里？告诉你错了就已经是在提醒你注意了，要是你找不到你错在哪里，那么显然你就不该写博客谈所谓的心得体会。

写博客你可以阐述观点，但是必须要有引证来证明。你写一堆心得体会，但是没有东西证明你这体会是正确的，那显然是有问题的。我也写博客，但是我很少写心得体会，一般只会引用别人的观点，然后加以阐述。如果阐述自己的观点，一定找出旁证来说明。

我费力帮你搜了martin fowler的原文：http://martinfowler.com/bliki/InversionOfControl.html

引用

There's a big difference now in the flow of control between these programs - in particular the control of when the process_name and process_quest methods are called. In the command line form I control when these methods are called, but in the window example I don't. Instead I hand control over to the windowing system (with the Tk.mainloop command). It then decides when to call my methods, based on the bindings I made when creating the form. The control is inverted - it calls me rather me calling the framework.

到底什么是控制反转？你的原文中的阐述：依赖对象的获得被反转。你看看和martin说的一样么？IoC和DI是完全2种不同的概念，这也是martin另外撰文阐述过：http://www.martinfowler.com/articles/injection.html。但是在你的博客中，却把2个东西说成是一个意思。

年轻人，态度决定一切。做技术如果不够严谨，光会思考也是不够的。少一分戾气，多一分执着。

"早在2004年，Martin Fowler就提出了“哪些方面的控制被反转了？”这个问题。他总结出是依赖对象的获得被反转了。基于这个结论，他为控制反转创造了一个更好的名字：依赖注入。--这不是我的原文,是martin说的,看到摘自维基百科了吗？再看spring技术内幕其中也是这句话

写博客你可以阐述观点，但是必须要有引证来证明难道这不算是证明吗？我觉得你太把自己当回事了，你的书我肯定不会买的！
维基百科原文地址：
http://zh.wikipedia.org/zh-cn/%E6%8E%A7%E5%88%B6%E5%8F%8D%E8%BD%AC

35 楼 zh_harry 2013-07-23  

downpour 写道

从一开始，理解就错了。所以我从来都不主张通过博客来表达所谓的心得体会，因为不正确的观点会通过博客散播开来造成对别人的误导。

其实downpour 所表达的观点是正确的，网上确实有很多个人观点对大家有误导，我曾经也深受其害，我想表达的是，其实这些东西是好是坏需要我们自己去分析和评价，每一个人所站在的立场不同，得到的结论也不同，但最终有一点，我们真正的理解了就可以了，至于谁对谁非这一点可以保留自己观点，没有必须争论的，我希望我所分享的不是结论，而是分析问题的方式方法和思考过程。

34 楼 downpour 2013-07-23  

zh_harry 写道

downpour 写道

从一开始，理解就错了。所以我从来都不主张通过博客来表达所谓的心得体会，因为不正确的观点会通过博客散播开来造成对别人的误导。

你说说什么地方是错的呢？我错没关系，我可以接受，我最不能接受的是不说出错在哪？你用意何在呢？

问题是我有什么义务告诉你错在哪里？告诉你错了就已经是在提醒你注意了，要是你找不到你错在哪里，那么显然你就不该写博客谈所谓的心得体会。

写博客你可以阐述观点，但是必须要有引证来证明。你写一堆心得体会，但是没有东西证明你这体会是正确的，那显然是有问题的。我也写博客，但是我很少写心得体会，一般只会引用别人的观点，然后加以阐述。如果阐述自己的观点，一定找出旁证来说明。

我费力帮你搜了martin fowler的原文：http://martinfowler.com/bliki/InversionOfControl.html

引用

There's a big difference now in the flow of control between these programs - in particular the control of when the process_name and process_quest methods are called. In the command line form I control when these methods are called, but in the window example I don't. Instead I hand control over to the windowing system (with the Tk.mainloop command). It then decides when to call my methods, based on the bindings I made when creating the form. The control is inverted - it calls me rather me calling the framework.

到底什么是控制反转？你的原文中的阐述：依赖对象的获得被反转。你看看和martin说的一样么？IoC和DI是完全2种不同的概念，这也是martin另外撰文阐述过：http://www.martinfowler.com/articles/injection.html。但是在你的博客中，却把2个东西说成是一个意思。

年轻人，态度决定一切。做技术如果不够严谨，光会思考也是不够的。少一分戾气，多一分执着。

33 楼 zh_harry 2013-07-23  

downpour 写道

从一开始，理解就错了。所以我从来都不主张通过博客来表达所谓的心得体会，因为不正确的观点会通过博客散播开来造成对别人的误导。

你从来不写博客吗？如果这样说你出书就不误导吗？真有意思

32 楼 zh_harry 2013-07-23  

downpour 写道

从一开始，理解就错了。所以我从来都不主张通过博客来表达所谓的心得体会，因为不正确的观点会通过博客散播开来造成对别人的误导。

你说说什么地方是错的呢？我错没关系，我可以接受，我最不能接受的是不说出错在哪？你用意何在呢？

31 楼 downpour 2013-07-23  

从一开始，理解就错了。所以我从来都不主张通过博客来表达所谓的心得体会，因为不正确的观点会通过博客散播开来造成对别人的误导。

30 楼 zh_harry 2013-07-23  

各位老大，觉得有问题可以加群讨论或在线把问题说出来。我会虚心接受并改正的。

29 楼 liutt 2013-07-23  

我觉得写得真不怎么样

28 楼 zh_harry 2013-07-23  

希望看过的兄弟把这篇文章再顶上来，我在写MVC相关文章，然后会讲框架，一路写下来，这是有关系，前边全是铺垫。谢谢各位了

27 楼 mike.liu 2013-07-23  

Motte2010 写道

zh_harry 写道

mike.liu 写道

Motte2010 写道

接口，只是说提倡使用接口变成的模式，并不是说你随便开发一个东西就需要用到接口。
如果你是需要为公司研发一套核心的框架，你可以考虑接口和各种设计模式；但是很多实际应用的开发中，很多人都是创建一个Service的时候加上一个接口，一般的时候，这个接口却只为一个类服务，这样的使用接口只会让系统越来越庞大，复杂，还不如直接使用实现类。
你写的IOC，没见哪里有你说的详细，笼统，看了等于没看，当然，一个IOC也不是一篇简单的博客，几行代码就能搞定的事。spring技术内幕中，是花了大量的篇幅。。。
个人意见而已，不是抨击。。。我也在学习。。。

我理解，用或不用接口，就是工厂生产与手工作坊的区别。

比如最初的计算机，基本上都是从新开始设计，从CPU，总线，存储，所有的架构都重新来。因此生产成本高，无法通用。计算机因此成为昂贵设备，只有少数人能够接触。

PC出现以后，标准化了总线结构。所有符合总线结构的设备，显卡、声卡、网卡，都可以往总线上面插。大家遵循的是接口。这样有利于扩展和独立发展。由此计算机能够进入寻常百姓家。

我理解，这是接口优势的一个明显的例子。

是这样的，接口就是为了扩展，这里边举的这个例子我觉得很棒，其实软件很多思想都是于源于现实生活的。

我的意思并不是不提倡使用接口，而是应当考虑是否确实有必要使用接口。如果我要为自己的公司研发一套自己的框架，这里肯定是需要考虑到扩展，使用接口。但是像我现在在公司开发的一般的网站，从我们业务上来说，完全没有用接口的必要，简单的增差改删，如果硬要给它套上一层接口，有点华而不实。

其实，接口这种东西，并不是程序世界才有的华丽概念。生活中大把大把接口的例子：银行窗口，电视机按钮……

而程序是什么？不就是对现实世界的模拟吗？

接口和实现分离，机制和策略分离。这些都是程序设计思想中的精髓。即使你的代码中没有interface这样的关键字，但是，始终还是离不开接口的概念。所有类的public方法，就可以组成这个类的接口，虽然是弱化的。即使在没有类的C语言里面，一个模块对外开放的所有函数，也可以理解为一个接口。

所以你写程序的时候，时时想到接口，是会对程序代码质量，可维护性，可扩展性，以及模块性带来莫大的好处。当然，如果你不需要考虑模块性，可维护性，可扩展性，那么是完全可以抛弃接口的。代码通常没有想象的那么稳定，需求改变、功能增强，随时都处于变化之中。接口在其中起的作用就是隔离变化带来的影响。

接口也有好有坏。我曾经遇到一个政府部门的办事的，得把材料交到窗口1，处理完毕，拿出来，再自己交到窗口2，再拿出来，再交到窗口3……，办完一个事情，郁闷得不行。能不能就一个窗口交材料，然后告诉我结果啊？这个接口的设计者，绝对是个弱智。但是我们的程序里面，大把这样的例子。

26 楼 zh_harry 2013-07-22  

Motte2010 写道

zh_harry 写道

mike.liu 写道

Motte2010 写道

接口，只是说提倡使用接口变成的模式，并不是说你随便开发一个东西就需要用到接口。
如果你是需要为公司研发一套核心的框架，你可以考虑接口和各种设计模式；但是很多实际应用的开发中，很多人都是创建一个Service的时候加上一个接口，一般的时候，这个接口却只为一个类服务，这样的使用接口只会让系统越来越庞大，复杂，还不如直接使用实现类。
你写的IOC，没见哪里有你说的详细，笼统，看了等于没看，当然，一个IOC也不是一篇简单的博客，几行代码就能搞定的事。spring技术内幕中，是花了大量的篇幅。。。
个人意见而已，不是抨击。。。我也在学习。。。

我理解，用或不用接口，就是工厂生产与手工作坊的区别。

比如最初的计算机，基本上都是从新开始设计，从CPU，总线，存储，所有的架构都重新来。因此生产成本高，无法通用。计算机因此成为昂贵设备，只有少数人能够接触。

PC出现以后，标准化了总线结构。所有符合总线结构的设备，显卡、声卡、网卡，都可以往总线上面插。大家遵循的是接口。这样有利于扩展和独立发展。由此计算机能够进入寻常百姓家。

我理解，这是接口优势的一个明显的例子。

是这样的，接口就是为了扩展，这里边举的这个例子我觉得很棒，其实软件很多思想都是于源于现实生活的。

我的意思并不是不提倡使用接口，而是应当考虑是否确实有必要使用接口。如果我要为自己的公司研发一套自己的框架，这里肯定是需要考虑到扩展，使用接口。但是像我现在在公司开发的一般的网站，从我们业务上来说，完全没有用接口的必要，简单的增差改删，如果硬要给它套上一层接口，有点华而不实。

是这样的，什么都没有绝对的，对于产品为了方便扩展和维护，是有必要的，小项目大可不必。

25 楼 Motte2010 2013-07-22  

zh_harry 写道

mike.liu 写道

Motte2010 写道

接口，只是说提倡使用接口变成的模式，并不是说你随便开发一个东西就需要用到接口。
如果你是需要为公司研发一套核心的框架，你可以考虑接口和各种设计模式；但是很多实际应用的开发中，很多人都是创建一个Service的时候加上一个接口，一般的时候，这个接口却只为一个类服务，这样的使用接口只会让系统越来越庞大，复杂，还不如直接使用实现类。
你写的IOC，没见哪里有你说的详细，笼统，看了等于没看，当然，一个IOC也不是一篇简单的博客，几行代码就能搞定的事。spring技术内幕中，是花了大量的篇幅。。。
个人意见而已，不是抨击。。。我也在学习。。。

我理解，用或不用接口，就是工厂生产与手工作坊的区别。

比如最初的计算机，基本上都是从新开始设计，从CPU，总线，存储，所有的架构都重新来。因此生产成本高，无法通用。计算机因此成为昂贵设备，只有少数人能够接触。

PC出现以后，标准化了总线结构。所有符合总线结构的设备，显卡、声卡、网卡，都可以往总线上面插。大家遵循的是接口。这样有利于扩展和独立发展。由此计算机能够进入寻常百姓家。

我理解，这是接口优势的一个明显的例子。

是这样的，接口就是为了扩展，这里边举的这个例子我觉得很棒，其实软件很多思想都是于源于现实生活的。

我的意思并不是不提倡使用接口，而是应当考虑是否确实有必要使用接口。如果我要为自己的公司研发一套自己的框架，这里肯定是需要考虑到扩展，使用接口。但是像我现在在公司开发的一般的网站，从我们业务上来说，完全没有用接口的必要，简单的增差改删，如果硬要给它套上一层接口，有点华而不实。

24 楼 dyccsxg 2013-07-22  

呵呵，看官方说明比较清楚
http://static.springsource.org/spring/docs/3.1.x/spring-framework-reference/html/beans.html

23 楼 zh_harry 2013-07-22  

mike.liu 写道

Motte2010 写道

接口，只是说提倡使用接口变成的模式，并不是说你随便开发一个东西就需要用到接口。
如果你是需要为公司研发一套核心的框架，你可以考虑接口和各种设计模式；但是很多实际应用的开发中，很多人都是创建一个Service的时候加上一个接口，一般的时候，这个接口却只为一个类服务，这样的使用接口只会让系统越来越庞大，复杂，还不如直接使用实现类。
你写的IOC，没见哪里有你说的详细，笼统，看了等于没看，当然，一个IOC也不是一篇简单的博客，几行代码就能搞定的事。spring技术内幕中，是花了大量的篇幅。。。
个人意见而已，不是抨击。。。我也在学习。。。

我理解，用或不用接口，就是工厂生产与手工作坊的区别。

比如最初的计算机，基本上都是从新开始设计，从CPU，总线，存储，所有的架构都重新来。因此生产成本高，无法通用。计算机因此成为昂贵设备，只有少数人能够接触。

PC出现以后，标准化了总线结构。所有符合总线结构的设备，显卡、声卡、网卡，都可以往总线上面插。大家遵循的是接口。这样有利于扩展和独立发展。由此计算机能够进入寻常百姓家。

我理解，这是接口优势的一个明显的例子。

是这样的，接口就是为了扩展，这里边举的这个例子我觉得很棒，其实软件很多思想都是于源于现实生活的。

22 楼 mike.liu 2013-07-22  

Motte2010 写道

接口，只是说提倡使用接口变成的模式，并不是说你随便开发一个东西就需要用到接口。
如果你是需要为公司研发一套核心的框架，你可以考虑接口和各种设计模式；但是很多实际应用的开发中，很多人都是创建一个Service的时候加上一个接口，一般的时候，这个接口却只为一个类服务，这样的使用接口只会让系统越来越庞大，复杂，还不如直接使用实现类。
你写的IOC，没见哪里有你说的详细，笼统，看了等于没看，当然，一个IOC也不是一篇简单的博客，几行代码就能搞定的事。spring技术内幕中，是花了大量的篇幅。。。
个人意见而已，不是抨击。。。我也在学习。。。

我理解，用或不用接口，就是工厂生产与手工作坊的区别。

比如最初的计算机，基本上都是从新开始设计，从CPU，总线，存储，所有的架构都重新来。因此生产成本高，无法通用。计算机因此成为昂贵设备，只有少数人能够接触。

PC出现以后，标准化了总线结构。所有符合总线结构的设备，显卡、声卡、网卡，都可以往总线上面插。大家遵循的是接口。这样有利于扩展和独立发展。由此计算机能够进入寻常百姓家。

我理解，这是接口优势的一个明显的例子。

21 楼 zh_harry 2013-07-22  

我再强调一下，我的文章是以最简单的方式来解释并实现最核心的功能，个人觉得是有助于学习和消化的。难道非要绕来绕去绕得大家晕晕的才有意思吗？脚着地静下心来想一想并试着去做一做，对自己的提高是有帮助的，看看我这篇是晚上1点多钟写的。太多的话我也不说了，实在觉得肤浅请绕过吧。谢谢