Ioc与容器——使用容器来管理组件

      面向对象设计的基本思想是将系统分解为一组可重用的对象，但如果没有一个核心模块来管理这些对象的话，它们将不得不各自去创建和管理自己的依赖，而这样的设计原则将使得这些对象变得紧紧的耦合在一起。

      对此，我们需要一个容器来管理这些系统对象，同时我们又不希望这个容器像EJB2.*版本时那样的复杂且笨拙，它应该做到足够的轻量。而我们需要在其中创建对象，并且对于使用者来说要提供类似于注册表式的键值方式查找服务，同时这个容器还应该具有管理对象的生命周期，为他们提供运行平台等等一些列功能。系统对象将成为这个容器中的一个个组件，它们的定义则应当严格遵守这个容器锁定下的规则。下面我们将以一些列的简单实现来体现一下我们的想法。

     首先我们假设要开发一个报表系统。根据“接口与实现相分离”的设计原则，我们可以对这个实现的借口做如下简单定义：

 

package com.demo.springdemo.report.generator.interf;

public interface ReportGenerator {
	public void generate(String[][] table);
}

     而在此我们假设这个接口有两个简单实现，其中的print语句只是简单的告诉我们代码什么时候被执行了。

package com.demo.springdemo.report.generator.impl;

import com.demo.springdemo.report.generator.interf.ReportGenerator;

public class HtmlReportGenerator implements ReportGenerator{

	@Override
	public void generate(String[][] table) {
		System.out.println("Generate HTML report ...");
	}

}

 

package com.demo.springdemo.report.generator.impl;

import com.demo.springdemo.report.generator.interf.ReportGenerator;

public class PdfReportGenerator implements ReportGenerator{

	@Override
	public void generate(String[][] table) {
		System.out.println("Generate PDF report ...");
	}

}

 同样，我们提供了一个Service来为用户提供具体的打印服务。

package com.demo.springdemo.report.service;

import com.demo.springdemo.report.generator.interf.ReportGenerator;

public class ReportService{

	private ReportGenerator reportGenerator = new PdfReportGenerator ();
	
	public void setReportGenerator(ReportGenerator reportGenerator) {
		this.reportGenerator = reportGenerator;
	}

	public void generateAnnualReport(int year) {
		String[][] statistics = null;
		/**
		 * 省略实现
		 */
		reportGenerator.generate(statistics);
	}

	public void generateMonthlyReport(int year, int month) {
		String[][] statistics = null;
		/**
		 * 省略实现
		 */
		reportGenerator.generate(statistics);
	}

	public void generateDailyReport(int year, int month, int day) {
		String[][] statistics = null;
		/**
		 * 省略实现
		 */
		reportGenerator.generate(statistics);
	}
}

    现在，由于ReportService是在内部创建的ReportGenerator 实例，所以它必须要知道将要使用的是哪一个具体ReportGenerator 实现类，这也就导致了ReportService对于ReportGenerator 实现类的直接依赖关系，而这个时候我们则可以通过一个容器来消除这种直接的依赖关系。假设容器实现如下：

package com.demo.springdemo;
...
public class Container{
      public static Container instance;

      private Map<String,Object> components;

      public Container (){
             components = new HashMap<String,Object>();
             instance = this;
             ReportGenator reportGenerator = new PdfReportGenerator();
             components.put("reportGenerator ",reportGenerator );

             ReportService reportService = new ReportService ();
             components.put("reportService ",reportService );
      }

      public Object getComponent(String id) {
             return components.get(id);
      }
}

    在这个简单的容器实现中，我们以Map形式来存储了各个组件。在容器的初始化过程中，把各个组件放入了Map中，以便于接下来的使用，并且提供了通过组建ID进行组建查找的获取方式。而在这当中，我们还利用了静态公共变量instance来存储容器的全局公共实例。至此，我们可以对于ReportService服务类做如下修改，

 

package com.demo.springdemo.report.service;
   ...
public class ReportService{

    private ReportGenerator reportGenerator = (ReportGenerator)Container.instance.getComponent("reportGenerator ");
    ...
}

    这个看似简单的修改也就意味着我们取消了ReportService对于ReportGenerator 具体实现的依赖关系，而当我们更换ReportGenerator 的具体实现的时候不许要在更改ReportService类了，而只需要为不同的需求来配置不同的容器实现即可，这也使得ReportService较之以前拥有了一定的重用性，但同时也使得ReportService对于容器产生了依赖关系，着同样也是个不怎么好的信号，问题如斯，尚待后面解决。

    简单的测试一下吧。

package com.demo;

import com.demo.springdemo.Container;
import com.demo.springdemo.report.service.ReportService;

public class Main {
	public static void main(String[] args) {
		Container container = new Container();
		ReportService reportService = (ReportService) container
				.getComponent("reportService");
		reportService.generateAnnualReport(2009);
	}
}

    如果看到了控制台打印出Generate PDF report ...，恭喜呢，成功了。

    纵观之上我们所做的一切，我们都做了些什么呢？做了个容器，然后简单的将配置从编程逻辑里面分离了出来，而这个看似简单的分离则减少了系统中不同组件之间的耦合度，也提高了各个组件的独立性和重用性，有待提高，继续学习，继感悟~~~