Hsuxu的专栏

任何重要的系统都需要至少两个相互合作的类来完成业务逻辑。通常，每个对象都要自己负责得到它的合作（依赖）对象。你会发现，这样会导致代码耦合度高而难以测试。使用Ioc，对象的依赖都是在对象创建时由负责协调系统中各个对象的外部实体提供的。这就是依赖被注入到对象中。所以，Ioc意味着关于对象如何得到它的协作对象的责任反转了。Ioc使软件组件松散链接成为可能，AOP让你能够捕捉系统中经常使用的功

传统的资源查找方式要求组件向容器发起请求来查找资源，作为回应，容器适时地返回资源。而应用了Ioc之后，则是容器主动地将资源推送到它所管理的组件里，组件所要做的仅仅是选择一种合适的方式来接受资源。这种行为被称为查找的被动形式。Ioc（控制反转）是一种通用的设计原则，而DI（依赖注入）则是具体的设计模式，它体现了Ioc的设计原则。在DI模式里，容易以一些预先定义好的方式（例如通过setter方法）

1.关于spring ioc 　这段时间也着实好好的看了下spring的相关书籍，对其也有了大概和初步的认识和理解，虽然之前也一直听说spring是一个非常优秀的开源框架，可一直没有机会学习和使用（是不是有点落伍了？呵呵），所以呢，这段时间就重点学习了spring（一个星期的时间当然是入门级的啦~~）　　大家一直都说spring的IOC如何如何的强大，其实我倒觉得不是IOC如何