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

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

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

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

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

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

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

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

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

[color=blue]之前对AOP的理解不到位，这里只论IOC的思想，感谢hippostart、rainsilence、云中苍月的提醒，其他补充如下：[/color]
已改，是我理解错了，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