IoC容器总结与简单模拟.docxVIP

IoC容器总结与简单模拟 　　当一个组件需要外部资源时，最直接也最明智的方法是执行查找，这种行为称为主动查找。但这种查找存在一个缺点——组件需要知道如何获得资源。一个好的获取资源的解决方案是应用IoC（Inversion of Control，控制反转）。它的思想是反转资源获取的方向。传统的资源查找方式是要求组件向容器发起请求来查找资源，作为回应，容器适时的返回资源。而应用了IoC之后，则是容器主动的将资源推送到它所管理的组件里，组件所要做的仅仅是选择一种合适的方式接受资源。 　　IoC是一种通用的设计原则，而DI（Dependency Injection，依赖注入）则是具体的设计模式，它体现了IoC的设计原则。DI是IoC典型的实现，所以IoC与DI术语会被混用。IoC与DI的关系就好比Java中的接口和接口的实现类的关系一样。 　　在DI模式下，容器全权负责的组件的装配，容器以一些预先定义好的方式（例如setter方法或构造函数）将匹配的资源注入到每个组件里。目前有三种类型的DI： setter注入，setter注入会存在一些问题，1. 容易出现忘记调用setter方法注入组件所需要的依赖，将会导致NullPointerException异常。2.?代码会存在安全问题，第一次注入后，不能阻止再次调用setter，除非添加额外的处理工作。但是由于setter注入非常简单所以非常流行（绝大多数Java IDE都支持自动生成setter方法）。 构造器注入，构造器注入能够一定程度上解决setter注入的问题。但是该中注入方式也会带来一些问题，如果组件有很多的依赖，则构造函数的参数列表将变得冗长，会降低代码可读性。 接口注入?，该注入方式使用的非常少，它要求组件必须实现某个接口，容器正是通过这个接口实现注入依赖的。接口注入的缺点比较明显，使用接口注入需要实现特定的接口，而接口又特定于容器，所以组件对容器产生了依赖，一旦脱离容器，组件不能重用。这是一种侵入式注入。 　　其中setter注入和构造器注入是被广泛运用的，绝大多数的IoC容器都支持这两种DI类型。 ? 模仿Spring?IoC容器 假设一个系统的功能之一是能够生成PDF或HTML格式的报表。 /*生成报表的通用接口*/public interface ReportBuilder{ public void build(String data);}  HYPERLINK javascript:void(0); 复制代码 生成PDF和HTML格式的实现类： /*生成HTML格式报表*/public class ReportHtmlBuilder implements ReportBuilder { @Override public void build(String data) { /*示意代码*/ System.out.println(build html report!); }}/*生成PDF格式报表*/public class ReportPdfBuilder implements ReportBuilder { @Override public void build(String data) { System.out.println(build pdf report!); }}  HYPERLINK javascript:void(0); 复制代码 报表服务类： /*报表服务类*/public class ReportService { /*依赖ReportBuilder*/ private ReportBuilder builder;  public ReportBuilder getBuilder() { return builder; }  /*setter注入*/ public void setBuilder(ReportBuilder builder) { this.builder = builder; } public void builderYearReport(int year) { this.builder.build(data); }}  HYPERLINK javascript:void(0); 复制代码 IoC容器配置文件component.properties pdfBuilder=com.beliefbitrayal.ioc.inte