演进式例解控制反转（IoC）、依赖注入（DI）之一

设计模式 前端之家
前端之家收集整理的这篇文章主要介绍了演进式例解控制反转（IoC）、依赖注入（DI）之一，前端之家小编觉得挺不错的，现在分享给大家，也给大家做个参考。

原文地址：http://haolloyin.blog.51cto.com/1177454/458416/


近来总是接触到IoC（Inversion of Control，控制反转）、DI（Dependency Injection，依赖注入）等编程原则或者模式，而这些是著名Java框架Spring、Struts等的核心所在。针对此查了Wikipedia中各个条目，并从图书馆借来相关书籍，阅读后有些理解，现结合书中的讲解以及自己的加工整理如下：

问题描述：

开发一个能够按照不同要求生成Excel或PDF格式的报表的系统，例如日报表、月报表等等。

解决方案：

根据“面向接口编程”的原则，应该分离接口与实现，即将生成报表的功能提取为一个通用接口ReportGenerator，并提供生成Excel和PDF格式报表的两个实现类ExcelGenerator和PDFGenerator，而客户Client再通过服务提供者ReportService获取相应的报表打印功能。

根据上面所述，得到如下类图：

代码实现： 
  1.  
       
    2.  
    3.   
    1. interfaceReportGenerator{
      2.  
    4.  
    5.   
    1. publicvoidgenerate(Tabletable);
      2.  
    6.  
    7.   
    1. }
      2.  
    8.  
    9.   
      2.  
    10.  
    11.   
    1. classExcelGeneratorimplementsReportGenerator{
      2.  
    12.  
    13.   
    1. voidgenerate(Tabletable){
      2.  
    14.  
    15.   
    1. System.out.println("generateanExcelreport...");
      2.  
    16.  
    17.   
    1. }
      2.  
    18.  
    19.   
    1. }
      2.  
    20.  
    21.   
      2.  
    22.  
    23.   
    1. classPDFGeneratorvoidgenerate(Tabletable){
      2.  
    24.  
    25.   
    1. System.out.println("generateanPDFreport...");
      2.  
    26.  
    27.   
    1. }
      2.  
    28.  
    29.   
    1. }
      2.  
    30.  
    31.   
      2.  
    32.  
    33.   
    1. classReportService{
      2.  
    34.  
    35.   
    1. //负责创建具体需要的报表生成器
      2.  
    36.  
    37.   
    1. privateReportGeneratorgenerator=newPDFGenerator();
      2.  
    38.  
    39.   
    1. @H_301_263@//privatestaticReportGeneratorgenerator=newExcelGenerator();
      2.  
    40.  
    41.   
      2.  
    42.  
    43.   
    1. voidgetDailyReport(Datedate){
      2.  
    44.  
    45.   
    1. table.setDate(date);
      2.  
    46.  
    47.   
    1. @H_301_263@//...
      2.  
    48.  
    49.   
    1. generator.generate(table);
      2.  
    50.  
    51.   
    1. }
      2.  
    52.  
    53.   
      2.  
    54.  
    55.   
    1. voidgetMonthlyReport(Monthmonth){
      2.  
    56.  
    57.   
    1. table.setMonth(month);
      2.  
    58.  
    59.   
    1. @H_301_263@//...
      2.  
    60.  
    61.   
    1. generator.generate(table);
      2.  
    62.  
    63.   
    1. }
      2.  
    64.  
    65.   
    1. }
      2.  
    66.  
    67.   
      2.  
    68.  
    69.   
      2.  
    70.  
    71.   
    1. classClient{
      2.  
    72.  
    73.   
    1. staticvoidmain(String[]args){
      2.  
    74.  
    75.   
    1. ReportServicereportService=newReportService();
      2.  
    76.  
    77.   
    1. reportService.getDailyReport(newDate());
      2.  
    78.  
    79.   
    1. @H_301_263@//reportService.getMonthlyReport(newDate());
      2.  
    80.  
    81.   
    1. }
      2.  
    82.  
    83.   
    1. }
      2.  
      1.
    问题描述：

    如上面代码中的注释所示，具体的报表生成器由ReportService类内部硬编码创建，由此ReportService已经直接依赖于PDFGenerator或ExcelGenerator，必须消除这一明显的紧耦合关系。

    解决方案： 引入容器

    引入一个中间管理者，也就是容器（Container），由其统一管理报表系统所涉及的对象（在这里是组件，我们将其称为Bean），包括ReportService和各个XXGenerator。在这里使用一个键-值对形式的HashMap实例来保存这些Bean。

    得到类图如下：

    代码实现： 
    1.  
         
      2.  
      3.   
      1. classContainer{
        2.  
      4.  
      5.   
      1. @H_301_263@//以键-值对形式保存各种所需组件Bean
        2.  
      6.  
      7.   
      1. privatestaticMap<String,Object>beans;
        2.  
      8.  
      9.   
        2.  
      10.  
      11.   
      1. publicContainer(){
        2.  
      12.  
      13.   
      1. beans=newHashMap<String,Object>();
        2.  
      14.  
      15.   
        2.  
      16.  
      17.   
      1. @H_301_263@//创建、保存具体的报表生起器
        2.  
      18.  
      19.   
      1. ReportGeneratorreportGenerator=newPDFGenerator();
        2.  
      20.  
      21.   
      1. beans.put("reportGenerator",reportGenerator);
        2.  
      22.  
      23.   
        2.  
      24.  
      25.   
      1. @H_301_263@//获取、管理ReportService的引用
        2.  
      26.  
      27.   
      1. ReportServicereportService=newReportService();
        2.  
      28.  
      29.   
      1. beans.put("reportService",reportService);
        2.  
      30.  
      31.   
      1. }
        2.  
      32.  
      33.   
        2.  
      34.  
      35.   
      1. staticObjectgetBean(Stringid){
        2.  
      36.  
      37.   
      1. returnbeans.get(id);
        2.  
      38.  
      39.   
      1. }
        2.  
      40.  
      41.   
      1. }
        2.  
      42.  
      43.   
        2.  
      44.  
      45.   
      1. @H_301_263@//消除紧耦合关系，由容器取而代之
        2.  
      46.  
      47.   
      1. @H_301_263@//privatestaticReportGeneratorgenerator=newPDFGenerator();
        2.  
      48.  
      49.   
      1. privateReportGeneratorgenerator=(ReportGenerator)Container.getBean("reportGenerator");
        2.  
      50.  
      51.   
        2.  
      52.  
      53.   
      1. voidgetDailyReport(Datedate){
        2.  
      54.  
      55.   
      1. table.setDate(date);
        2.  
      56.  
      57.   
      1. generator.generate(table);
        2.  
      58.  
      59.   
      1. }
        2.  
      60.  
      61.   
        2.  
      62.  
      63.   
      1. voidgetMonthlyReport(Monthmonth){
        2.  
      64.  
      65.   
      1. table.setMonth(month);
        2.  
      66.  
      67.   
      1. generator.generate(table);
        2.  
      68.  
      69.   
      1. }
        2.  
      70.  
      71.   
      1. }
        2.  
      72.  
      73.   
        2.  
      74.  
      75.   
      1. voidmain(String[]args){
        2.  
      76.  
      77.   
      1. Containercontainer=newContainer();
        2.  
      78.  
      79.   
      1. ReportServicereportService=(ReportService)Container.getBean("reportService");
        2.  
      80.  
      81.   
      1. reportService.getDailyReport(@H_301_263@//reportService.getMonthlyReport(newDate());
        2.  
      82.  
      83.   
      1. }
        2.  
      84.  
      85.   
      1. }
        2.  
        1.
      时序图大致如下：

      效果：

      如上面所示，ReportService不再与具体的ReportGenerator直接关联，已经用容器将接口和实现隔离开来了，提高了系统组件Bean的重用性，此时还可以使用配置文件在Container中实时获取具体组件的定义。

      问题描述：

      然而，观察上面的类图，很容易发现ReportService与Container之间存在双向关联，彼此互相有依赖关系。并且，如果想要重用ReportService，由于它也是直接依赖于单独一个Container的具体查找逻辑。若其他容器具体不同的组件查找机制（如JNDI），此时重用ReportService意味着需要修改Container的内部查找逻辑。

      解决方案： 引入 Service Locator

      再次引入一个间接层Service Locator，用于提供组件查找逻辑的接口，请看Wikipedia中的描述或者Java EE对其的描述1、描述2。这样就能够将可能变化的点隔离开来。

      类图如下：

      代码实现： 
      1.  
           
        2.  
        3.   
        1. @H_301_263@//实际应用中可以是用interface来提供统一接口
          2.  
        4.  
        5.   
        1. classServiceLocator{
          2.  
        6.  
        7.   
        1. staticContainercontainer=newContainer();
          2.  
        8.  
        9.   
          2.  
        10.  
        11.   
        1. staticReportGeneratorgetReportGenerator(){
          2.  
        12.  
        13.   
        1. return(ReportGenerator)container.getBean("reportGeneraator");
          2.  
        14.  
        15.   
        1. }
          2.  
        16.  
        17.   
        1. }
          2.  
        18.  
        19.   
          2.  
        20.  
        21.   
        1. privateReportGeneratorreportGenerator=ServiceLocator.getReportGenerator();
          2.  
        22.  
        23.   
          2.  
        24.  
        25.   
        1. @H_301_263@//...
          2.  
        26.  
        27.   
        1. }
          2.  
          1.


        小结：

        1、虽然讲了这么大篇幅还没有进入真正的主题——IoC、DI，不过已经在一步步逼近了，下一篇应该会更精彩！在这里...

        2、可以很明显地看得出上面两中重新设计以解耦、隔离变化点都是通过引入间接层得以解决的。

        3、在看书过程中，我感觉《Spring攻略》一书中以“问题描述、解决方案、实现方法”方式的讲解比较容易理解和理清思路，故而也学习用这种方式来写。另，推荐该书以学习Spring框架（尽管目前我看得也不多）。

        猜你在找的设计模式相关文章

        适配器模式-让不兼容的接口得以适配
        适配器模式将一个类的接口转换成客户期望的另一个接口，使得原本接口不兼容的类可以相互合...
        策略模式-定义一个算法族
        策略模式定义了一系列算法族，并封装在类中，它们之间可以互相替换，此模式让算法的变化独...
        设计模式之高质量代码
        设计模式讲的是如何编写可扩展、可维护、可读的高质量代码，它是针对软件开发中经常遇到的...
        模板方法模式-封装一套算法流程
        模板方法模式在一个方法中定义一个算法的骨架，而将一些步骤延迟到子类中，使得子类可以在...
        迭代器模式-统一集合的遍历方式
        迭代器模式提供了一种方法，用于遍历集合对象中的元素，而又不暴露其内部的细节。
        单例模式的五种实现方式及优缺点
        单例模式（Singleton Design Pattern）保证一个类只能有一个实例，并提供一个全局访问点。
        组合模式-统一的处理个别对象与组合对象
        组合模式可以将对象组合成树形结构来表示“整体-部分”的层次结构，使得客户可以用一致的方...
        装饰者模式-动态的包装原有对象的行为
        装饰者模式能够更灵活的，动态的给对象添加其它功能，而不需要修改任何现有的底层代码。
        观察者模式-将消息通知给观察者
        观察者模式（Observer Design Pattern）定义了对象之间的一对多依赖，当对象状态改变的时候...
        代理模式-访问对象的代理而非其本身
        代理模式为对象提供一个代理，来控制对该对象的访问。代理模式在不改变原始类代码的情况下...
        算法设计模式多媒体技术正则表达式ElasticsearchFlinkHadoopIDE
        受约束摘*day25Java常用类库置信lamda留存持续录入年后正则表达式303.17regularexpre匹多模适20130322基础理论pathmunge涵义reectok需要转义的特资源分享validationex简明魔法里弄形如源码实现完备actionscript