美文网首页
学习笔记:理解IoC

学习笔记:理解IoC

作者: 大力papa | 来源:发表于2020-12-30 17:10 被阅读0次

    本文仅供学习交流使用,侵权必删。
    不作商业用途,转载请注明出处

    IoC

    Inversion of Control principle是一种面向对象的编程设计模式,可以用来降低代码的耦合度。IoC也会被戏称为Hollywood Principle: Don't call us, we'll call you。
    对于用传统编程方式开发的程序,每个事件的调用、依赖管理以及组件管理都需要业务系统去完成。
    而对于IoC原则开发的程序,将会使用一个框架来进行程序开发,如我们比较熟悉的Spring。框架已经了解常见的行为,我们只需要将完成业务组件的开发注册到框架中。框架能够针对用户触发的事件去调用我们注册进去的业务组件,并且能够帮我们管理这些组件。这种开发方式能有效提高我们的开发效率,工程师只需要专注于业务组件的开发。

    IoC设计目的

    1. 将任务的执行和实现解耦
    2. 让开发人员专注于设计业务模块代码上
    3. 利用依赖契约将模块从系统中解放出来
    4. 避免模块变更时产生的副作用

    IoC实现技术:

    1. 服务定位器模式(service locator pattern)
    2. 依赖注入
    3. 依赖查找
    4. 模板设计模式
    5. 策略模式

    Dependency Injection

    在Spring官网中解释IoC一般也被称为依赖注入(Dependency Injection),但其实DI只是IoC的其中一种实现方式。而Spring中的控制反转指的是对于组件的控制权由用户转移到框架中。
    传统的方式我们是需要主动去创建或者主动查找具体的实现类。而Spring的IoC是让容器去管理这些组件的生命周期以及注入。


    image.png

    假设我们有一个授信Controller接口对用户提供授信查询功能。根据DI的基本思想,
    授信Controller并不直接依赖授信查询的具体实现类,只依赖于授信查询接口。而具体的实现类是由容器创建并注入到我们的Controller中

    DI实现的三种方法

    1. 构造器注入
    2. setter注入
    3. 接口注入

    在Spring Framework中,实现了通过构造器注入和setter注入。通过构造器和setter实现DI的优势是只要遵循简单的约定即可(定义好构造器或者定义好setter方法),无需在我们的业务组件中入侵其他非业务代码。

    构造器注入 VS setter注入

    从Martin Flower的观点和Spring官方文档中可以看到,他们更加倾向于开发人员使用构造器注入的方式。首先带参数的构造器能够清楚说明创建一个有效对象时的含义。其次构造器注入能够确保对象是稳定不变对象,如果开放setter方法有可能会降低对象的稳定性。
    但构造器注入也并非一直是best choice,这种方式注入同样存在问题。如果构造器参数过多,会让构造函数看起来较为混乱,可读性较差。其次有过多的构造函数或者过多的继承关系。在初始化时就会调用每个超类的构造函数,这可能导致构造函数爆炸。如果存在上述问题的情况下,setter方法有可能是更好的选择。

    参考文献

    [wiki] https://en.jinzhao.wiki/wiki/Inversion_of_control
    [Inversion of Control Containers and the Dependency Injection pattern​] https://www.martinfowler.com/articles/injection.html
    [spring官方文档​] https://docs.spring.io/spring-framework/docs/5.2.12.RELEASE/spring-framework-reference/core.html#spring-core

    相关文章

      网友评论

          本文标题:学习笔记:理解IoC

          本文链接:https://www.haomeiwen.com/subject/bnshoktx.html