控制反转（IoC）

时间  2019-11-12
标签 控制 反转 ioc 繁體版
原文   原文链接
 
 
 
大量使用工厂模式引发的问题：
 
    Client 对象须要使用 Service1 的 execute( ) 方法完成特定功能，而 Service1 的实现 Service1Impe类又依赖于 Service2的实现类 Service2Impl，为了减小依赖，咱们为 Service1 和 Service2对象的实例化分别提供工厂方法类的实现。
  
public interface Service1 {
    void execute();
}
 
public class Service1Impl implements Service1 {
 
    private Service2 service2;
 
    public Service1Impl(Service2 service2) {
        this.service2 = service2;
    }
 
    @Override
    public void execute() {
        System.out.println("Service1 is doing something.");
 
        service2.execute();
    }
 
}
 
public interface Service2 {
    void execute();
}
 
public class Service2Impl implements Service2 {
 
    @Override
    public void execute() {
        System.out.println("Service2 is doing something.");
    }
 
}
 
// 工厂类的实现
public class Service2Factory {
    public static Service2 getService2Instance() {
        return new Service2Impl();
    }
}
 
public class Service1Factory {
    public static Service1 getService1Instance() {
        Service2 service2 = Service2Factory.getService2Instance();
        return new Service1Impl(service2);
    }
 
}
 
// 测试代码
public class Client {
    public void doSomething() {
        Service1 service = Service1Factory.getService1Instance();
        service.execute();
    }
}
-- Service1 is doing something.
-- Service2 is doing something.

 

 
大规模地使用工厂方法模式，会引发诸多问题：
  • 工厂类泛滥：在实际应用中，常常出现几百个像这样的服务类，若是使用工厂方法模式的话，就可能出现几百个这样的工厂类。由于不知道未来会产生多少子类扩展系统，因此也不能使用静态工厂模式。
  • 依赖关系复杂：每每这几百个 Service对象之间存在复杂的依赖关系，工厂类的装配逻辑也随之变得十分复杂。增长了装配这些服务对象的精力，而不能专一于业务功能的开发。
  • 不易进行单元测试。
 
Inversion of Control（控制反转）：
好莱坞原则：不要找咱们，咱们会找你。
咱们常常把控制逻辑写在其余地方而非客户化的代码里，这样就能够更专一与客户化的逻辑，即外部逻辑负责调用客户化的逻辑。在软件开发领域，取名叫：控制反转（IoC）。
 
应用实例：
  • 模板方法模式——父类的模板方法控制子类的方法调用
  • 回调的方法也是控制反转的很好应用。
  • 在 Java标准库里，查找（binarySearch） 和 排序（sort）这两个方法，他们在执行过程当中会调用对象的 compareTo( ) 方法（若是这些对象实现了 java.lang.Comparable 接口的话），或者调用咱们所传递的回调接口 java.util.Comparator 对象的 compare( ) 方法来比较大小，最终完成查找/排序操做。
  • 框架：框架抽象了通用流程，咱们能够经过框架提供的规范（如子类化抽象类或者实现相关的接口，实现相关的交互协议和接口等）就能够把客户化的代码植入流程中，完成各类定制的需求。
 
框架和工具库（Library）的区别是：若是框架没有实现控制反转，那么框架就会退化为工具库。也就是说，使用工具库，必须撰写调用它们的逻辑，每次调用它们都会完成相应的工做，并把控制权返回给调用者；而框架不须要客户程序撰写控制调用的逻辑，由框架专门负责。
 
IoC 和 DI：
    任何容器/框架都实现了控制反转，它们所说的控制反转指的是 对服务/对象/组件的实例化和查找实现了控制反转，这只是控制反转的一种而已。
 
实现控制反转主要有两种形式：
  • Service Locator（服务定位器）
  • Dependency Injection（依赖注入，简写为 DI）
 
Service Locator（服务定位器）：
 
    服务定位器封装了查找逻辑，隐藏了服务/对象/组件之间的依赖关系，为它们提供了一个全局的入口。客户对象只要依赖于它就能获取想要的组件/服务/对象。
 
    工厂方法模式和服务定位器的区别是：服务定位器为整个应用组件/服务/对象的获取提供了单一的入口，而一个工厂只提供特定类型的实例化，若是一个工厂能提供全部组件/服务/对象的装配和实例化，那它就被进化为服务定位器。
 
    使用服务定位器时，容器/框架侵入了代码，下降了代码移植性，单元测试也相对比较麻烦。
    
 
 
 
    简单的服务定位器： 
//简单的服务定位器
public class ServiceLocator {
    private static ServiceLocator locator;
    // 建立 HashMap<String, Object>对象来持有这些服务对象
    private Map<String, Object> services = new HashMap<String, Object>();
 
    // 初始化容器
    public static void configure() {
        load(new ServiceLocator());
 
        // Service一、Service2的对象实际上是按照单例建立的
        Service2 service2 = new Service2Impl();
        locator.services.put("service2", service2);
        Service1 service1 = new Service1Impl(service2);
        locator.services.put("service1", service1);
    }
 
    private static void load(ServiceLocator serviceLocator) {
        locator = serviceLocator;
    }
 
    public static Object lookup(String serviceName) {
        return locator.services.get(serviceName);
    }
 
    public static void registerService(String name, Object service) {
        locator.services.put(name, service);
    }
}

 

 
Client类的实现：
  
public class Client {
    public void doSomething() {
 
        Service1 service1 = (Service1) ServiceLocator.lookup("service1");
        service1.execute();
    }
 
    // 测试代码
 
    public static void main(String[] args) {
        // 初始化容器
        ServiceLocator.configure();
 
        new Client().doSomething();
    }
}

 

 
 
Dependency Injection（依赖注入）：
 
    外部程序把服务对象经过某种方式注入到客户对象供其使用的方法称之为 依赖注入。
根据 注入方式的不一样，把依赖注入分为 6类：
  1. Setter 注入：外部程序经过调用 setting方法为客户对象注入所依赖的对象。（Spring框架是使用反射机制调用 setting方法注入依赖的对象）
  2. Constructor 注入：经过带参数的构造方法注入依赖对象。
  3. Annotation 注入：把实例化信息和对象之间的依赖关系信息使用 Annotation注解。
  4. Interface 注入：客户程序经过实现容器/框架所规范的某些特殊接口，在为客户对象返回这些依赖的对象以前，容器回调这些接口的方法，注入所依赖的服务对象。如：Struts2中的 Action实现了接口 ServletRequesetAware、SessionAware等，只要 Action类实现这些接口，Struts框架就会调用这些接口的相应方法，注入 HttpServletRequest、HttpSession对象。
  5. Parameter 注入 ：外部程序能够经过函数参数，给客户程序注入所依赖的服务对象。
  6. 其它形式的注入
 
    Setter 和 Constructor 是最多见的注入方式，代码每每不会受到容器/框架的入侵，能够在多种轻量级容器上移植，而其它方式或多或少都受到容器/框架代码的入侵。
 
 
Interface 注入：（这种方式不够灵活，容器必须预先定义一些接口实现注入，适合实现少数特定类型的对象注入）
  
// ServiceAware 接口
public interface ServiceAware {
    void injectService(Service service);
}
// Service 接口及其实现类
public interface Service {
    void excute();
}
public class ServiceImpl implements Service {
 
    @Override
    public void excute() {
        System.out.println("Service is doing something...");
    }
 
}
 
// 建立简单的接口注入容器
public class InterfaceInjector {
 
    private static InterfaceInjector injector;
    private Map<Class, Object> services = new HashMap<Class, Object>();
 
    // 安装容器
    public static void configure() {
        load(new InterfaceInjector());
    }
 
    public static <T> T getInstance(Class<T> clazz) {
        return injector.loadService(clazz);
    }
 
    private static void load(InterfaceInjector container) {
        InterfaceInjector.injector = container;
 
    }
 
    private <T> T loadService(Class<T> clazz) {
 
        Object service = injector.services.get(clazz);
 
        if (service != null) {
            return (T) service;
        }
 
        try {
            // 建立 clazz类实例
            service = clazz.newInstance();
            // 经过接口装配依赖的对象,若是对象是 ServiceAware的实例为真
            if (service instanceof ServiceAware) {
                // 则调用此接口的方法注入 ServiceAware对象
                ((ServiceAware) service).injectService(new ServiceImpl());
            }
            injector.services.put(clazz, service);
        } catch (Exception e) {
            e.printStackTrace();
        }
 
        return (T) service;
    }
 
}
 
// 只要服务类实现这个接口，容器就会注入 Service对象,定义一个 Client类实现该接口 
public class Client implements ServiceAware {
 
    private Service service;
 
    @Override
    public void injectService(Service service) {
        this.service = service;
    }
 
    public void doSomething() {
        service.excute();
    }
 
    public static void main(String[] args) {
        InterfaceInjector.configure();
        Client client = InterfaceInjector.getInstance(Client.class);
        client.doSomething();
    }
}
    -- Service is doing something...

 

 
 
Parameter 注入 ：外部程序能够经过函数参数，给客户程序注入所依赖的服务对象。 
//参数注入
public class Client {
    // 外部程序经过函数参数，给客户程序注入所依赖的服务对象
    // 采用外部传递 Service对象方式,至于Service如何实例化,它一无所知
    public void dosomething(Service service) {
        service.excute();
    }
 
 
    // 使用方法：外部程序实例化一个 Service实例,传递给 Client的 dosomething(Service service)方法使用
    public static void main(String[] args) {
        Service service = new ServiceImpl();
        new Client().dosomething(service);
    }
}

 

注意：这种形式的注入比较特殊，Client 类的 dosomething(Service service) 方法不光完成了依赖的装配，并且执行了 Service 回调的方法 execute( )，完成了其它逻辑。
 
Setter 和 Constructor 注入都是一种特殊的参数注入，它规定了只能使用 setting方法注入依赖 或者 只能对构造函数实现参数注入。
 
一些流行 DI 框架在使用参数注入实例化对象时，每每结合 Annotation注入、Interface 注入等方式一块儿使用，可是明显的一条，这些实现方法不该包含除依赖装配以外的其它逻辑。
 
其它形式的注入：
    容器/框架提供一些高级用法，主要用来解决一些特殊问题。如：Spring框架的 lookup方法注入方式。使用场景：一个singleton的Bean须要引用一个prototype的Bean; 一个无状态的Bean须要引用一个有状态的Bean; ... ; 等等情景下，通常用的很少。
 
 
总结：
  • IoC使得客户专一于客户化的逻辑设计，把程序流程的控制交给外部代码，实现高内聚低耦合目标。
  • 把实例化的过程交给框架/容器来处理，使得咱们更专一于业务逻辑的开发。
相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程