随笔：用spring之前对IOC的体会

    第一次接触IOC是还在大学的时候，那时候还什么都不懂，不懂OO，不懂设计模式，只知道要用什么就new什么，也没人管我们，老师更不管，那时老师还没先进到工厂模式上，如果说new的方式是原始社会的话，那么我很不幸的说，那会却生活在原始社会。
    如果说IOC是资本主义社会的话，那么我想我那会还没体会到资本主义的优越性。毕业1年了，也在大型项目里奋斗着，在工作中，上头不会管你如何实现，而关心的是东西的可靠性、可维护性、可配性、系统边界、系统交互等，而软件工程的命运完全掌握在自己手里。
    所以我想这1年里，我更多地是自己写配置文件和设计模式，自己思考聚合和耦合是什么东西，听说设计模式是前人的的精华，所以我奋力取之而不亦乐乎。似乎也很奇怪，如果说设计模式是社会主义社会，项目组似乎都在社会主义社会里构建起几乎所有构架。

    也不怕大家笑话，确实没用过spring，对spring了解甚少，但相信很多东西都是想通的，现在去重温大学时代那个的IOC之时，确有新的感悟。
    IOC的思想最早是1996年从C++领域提出来的，虽然OO的流行大大提高了重用性和可扩展性，可当时人们可能还是觉得业务模块还不够清晰、也不够灵活，各种业务逻辑里弥漫着设计模式“冗余”代码，从而想剥离这部分，随之而然，IOC的思想浮出水面。

    关于可配
    把这种组织工作转移给框架（比如spring容器），编译期不必知道是谁来实现，而只关心业务逻辑，并装载这些组件的工作在运行期通过配置来确定，如果说设计模式是一种代码级的硬耦合，那么IOC是一种配置级的硬耦合吧？！不过给人的感觉修改配置文件比修改代码的可配性要高。

    关于解耦
    想想，在设计模式上，调用类用工厂模式请求了被调用类，看上去被写死在代码级别上了，所以是编译期确定。
    在IOC上，宿主类在代码级别上不关心具体哪个类去实现，只要“未知类”实现了我的接口就行，在运行期由容器去加载实现类，所以可以运行期确定。

    嗯，看来我似乎是一步步走过来的？也是被教育毒害的孩子。

    接受新事务之前，我心存怀疑，IOC的缺点是什么？或者该踏入Ruby的海洋？

    关于效果
以上纯属个人的理解，有不正确之处，还请批评和指正。

---------------------------cut line-------------------

之前对AOP的理解不到位，这里只论IOC的思想，感谢hippostart、rainsilence、云中苍月的提醒，其他补充如下：
已改，是我理解错了，IOC和AOP这两个东西不属于同一概念，概念被混淆了。

因为中文一下字没有找到有效信息，就用google.com找到如下：

Asking for differences between IoC and AOP is kind of like asking the difference between apples and oranges.

Aspect-Oriented Programming (AOP) is concerned mainly with abstracting functionality that applies across the board to many components of your application. For example, logging and security. These have little or nothing to do with the actual business functionality but are essential system-wide functions nonetheless.

Inversion of Control (IoC), a.k.a. Dependency Injection (DI) is concerned with maintaining loose coupling and managing the dependencies between the components of an application. 

两个概念就像苹果和橘子，AOP主要关心那些用于组件的所有公共功能，像日志，安全等，而IOC主要是达到组件间的松耦合。

Aspect-Oriented Programming (AOP) complements OOP by providing another way of thinking about program structure. While OO decomposes applications into a hierarchy of objects, AOP decomposes programs into aspects or concerns. This enables modularization of concerns such as transaction management that would otherwise cut across multiple objects. (Such concerns are often termed crosscutting concerns.)

--->截自http://static.springsource.org/spring/docs/1.2.x/reference/aop.html

这样的标题，这样的内容

只说明LZ对IOC和AOP基本一无所知

LZ埋头写程序吧，少发言。

嗯，确实是我知之甚少。
我只是写出了一点薄见，目的也是想大家指正我的理解。

改了下标题，觉得更合适，呵呵。

把aop和ioc混为一谈，你就不能google一下再发帖吗！！

感觉像小学生写作文。

我google出来的结果，经自己的理解后是：AOP是面向切面编程，和OP、OO同属同一层概念，而IOC是AOP的基础或者说实现方式，
OO编程是把数据和动作抽象化，通过new出对象或者运用一定设计模式组织这些对象，而AOP更想支离出那些非业务逻辑，降低对象间的耦合性，让框架自己管理组件关系而提出来的。

以上都是自己的理解。
如果有不对的地方，你完全可以提出来。
你也完全可以说说自己的理解。
有必要用“小学生写的作文”等话来讽刺？呵呵
我只是有点好奇，当你写这句话的时候？ 到底是个什么心态呢？


====》以上理解不正确，IOC和AOP不属于同一概念。

lz说：IOC是AOP的基础或者说实现方式。。。。

我觉得你应该继续google。。。。

还有文章标题应该改为对IOC的体会。。。

“小学生写的作文”的说法言辞比较直接，可能刺伤楼主自尊了。不过在我看来，实话实说，这个评价挺准确……希望楼主能多学习和阅读前辈高人关于AOP以及IOC（DI）的文章，并且多多应用实践，等有了切身体会后再发帖不迟。

论坛有风险，发帖需谨慎。

楼上各位的回复的确有点狠，谁不是一步步走过来呢，没说对直接指出来就可以了，没必要句句刺人。
回楼主:ioc和Aop是不同的，你本文说的应该是Ioc,而且体会到位，而Aop是切面介入的模式，我用手机发帖，就不细讲了，你阅读一下Spring中文手册就有答案了