• Spring 之 控制反转(IoC), 依赖注入(DI)和面向切面(AOP)


    关于依赖注入, 这篇博文写的非常简单易懂.

    https://github.com/android-cn/blog/tree/master/java/dependency-injection

    此外, 博文http://blog.csdn.net/hy6688_/article/details/40658835 中介绍了IoC的三种常见DI实现方式. - 构造器注入, Setter注入, 接口注入.

    依赖注入(DI)--(dependency-injection)

    1. 依赖 如果在 Class A 中,有 Class B 的实例,则称 Class A 对 Class B 有一个依赖。例如下面类 Human 中用到一个 Father 对象,我们就说类 Human 对类 Father 有一个依赖。

    public class Human {
        ...
        Father father;
        ...
        public Human() {
            father = new Father();
        }
    }

    仔细看这段代码我们会发现存在一些问题:
    (1). 如果现在要改变 father 生成方式,如需要用new Father(String name)初始化 father,需要修改 Human 代码;
    (2). 如果想测试不同 Father 对象对 Human 的影响很困难,因为 father 的初始化被写死在了 Human 的构造函数中;
    (3). 如果new Father()过程非常缓慢,单测时我们希望用已经初始化好的 father 对象 Mock 掉这个过程也很困难。

    2. 依赖注入 上面将依赖在构造函数中直接初始化是一种 Hard init 方式,弊端在于两个类不够独立,不方便测试。我们还有另外一种 Init 方式,如下:

    public class Human {
        ...
        Father father;
        ...
        public Human(Father father) {
            this.father = father;
        }
    }

    上面代码中,我们将 father 对象作为构造函数的一个参数传入。在调用 Human 的构造方法之前外部就已经初始化好了 Father 对象。像这种非自己主动初始化依赖,而通过外部来传入依赖的方式,我们就称为依赖注入。
    现在我们发现上面 1 中存在的两个问题都很好解决了,简单的说依赖注入主要有两个好处:
    (1). 解耦,将依赖之间解耦。
    (2). 因为已经解耦,所以方便做单元测试,尤其是 Mock 测试。

    3. Java 中的依赖注入

    依赖注入的实现有多种途径,而在 Java 中,使用注解是最常用的。通过在字段的声明前添加 @Inject 注解进行标记,来实现依赖对象的自动注入。

    public class Human {
        ...
        @Inject Father father;
        ...
        public Human() {
        }
    }

    上面这段代码看起来很神奇:只是增加了一个注解,Father 对象就能自动注入了?这个注入过程是怎么完成的?

    实质上,如果你只是写了一个 @Inject 注解,Father 并不会被自动注入。你还需要使用一个依赖注入框架,并进行简单的配置。现在 Java 语言中较流行的依赖注入框架有 Google GuiceSpring 等,而在 Android 上比较流行的有 RoboGuiceDagger 等

    控制反转(IoC)--(Inversion of Control)

    IoC, 参见: http://blog.163.com/xianghuxian@126/blog/static/50639037200721345218382/

    IoC(Inversion of Control),这是spring的核心,贯穿始终。所谓IoC,对于spring框架来说,就是由spring来负责控制对象的生命周期和对象间的关系。这是什么意思呢,举个简单的例子,我们是
    如何找女朋友的?常见的情况是,我们到处去看哪里有长得漂亮身材又好的mm,然后打听她们的兴趣爱好、qq号、电话号、手机号、MSN………,想办法认识她们,投其所好送其所要,然后嘿嘿……这个过程是复杂
    深奥的,我们必须自己设计和面对每个环节。传统的程序开发也是如此,在一个对象中,如果要使用另外的对象,就必须创建它(自己new一个,或者从JNDI中查询一个),使用完之后还要将对象销毁(比如
    ,Connection等),对象始终会和其他的接口或类藕合起来。   那么IoC是如何做的呢?有点像通过婚介找女朋友,在我和女朋友之间引入了一个第三方机构:婚姻介绍所。婚介管理了很多男男女女的资料,我可以向婚介所提出一个列表,告诉它我想找个什么样的女
    朋友,比如长得像李嘉欣,身材像林林志玲,唱歌像刘德华,速度像刘翔,身高像姚明之类的,然后婚介就会按照我们的要求,提供一个mm,我们只需要去和她谈恋爱、结婚就行了。简单明了,如果婚介给我
    们的人选不符合要求,我们就会抛出异常。整个过程不再由我自己控 制,而是有婚介这样一个类似容器的机构来控制。Spring所倡导的开发方式就是如此,所有的类都会在spring容器中登记,告诉spring
    你是个什么东西,你需要什么东西,然后spring会在系统运行到适当的时候,把你要的东西主动给你,同时也把你交给其他需要你的东西。所有的类的创建、销毁都由spring来控制,也就是说控制对象生存
    周期的不再是引用它的对象,而是spring。对于某个具体的对象而言,以前是它控制其他对象,现在是所有对象 都被spring控制,所以这叫控制反转。如果你还不明白的话,我决定放弃。 IoC的一个重点是在系统运行中,动态的向某个对象提供它所需要的其他对象这一点是通过DI(Dependency Injection,依赖注入)来实现的。比如对象A需要操作数据库,以前我们总是要在A中自
    己编写代码来获得一个Connection对象,有了spring我们就只需要告诉spring,A中需要一个Connection,至于这个Connection怎么构造,何时构造,A不需要知道。在系统 运行时,spring会在适当的
    时候制造一个Connection,然后像打针一样,注射到A当中,这样就完成了对各个对象之间关系的控制。A需要依赖 Connection才能正常运行,而这个Connection是由spring注入到A中的,依赖注入的名
    字就这么来的。那么DI是如何实现的呢? Java 1.3之后一个重要特征是反射(reflection),它允许程序在运行的时候动态的生成对象、执行对象的方法、改变对象的属性,spring就是通过反射来实现
    注入的。


    面向切面(AOP)--(Aspect oriented
    programming)
    AOP参考:https://www.zhihu.com/question/24863332/answer/48376158
      面向切面编程(AOP是Aspect Oriented Program的首字母缩写) ,我们知道,面向对象的特点是继承、多态和封装。而封装就要求将功能分散到不同的对象中去,这在软件设计中往往称为职责分配。实际上也就是说,让不同的类设计不同的方法。这样代码就分散到一个个的类中去了。这样做的好处是降低了代码的复杂程度,使类可重用。
    但是人们也发现,在分散代码的同时,也增加了代码的重复性。什么意思呢?比如说,我们在两个类中,可能都需要在每个方法中做日志。按面向对象的设计方法,我们就必须在两个类的方法中都加入日志的内容。也许他们是完全相同的,但就是因为面向对象的设计让类与类之间无法联系,而不能将这些重复的代码统一起来。
    也许有人会说,那好办啊,我们可以将这段代码写在一个独立的类独立的方法里,然后再在这两个类中调用。但是,这样一来,这两个类跟我们上面提到的独立的类就有耦合了,它的改变会影响这两个类。那么,有没有什么办法,能让我们在需要的时候,随意地加入代码呢?这种在运行时,动态地将代码切入到类的指定方法、指定位置上的编程思想就是面向切面的编程。
      一般而言,我们管切入到指定类指定方法的代码片段称为切面,而切入到哪些类、哪些方法则叫切入点。有了AOP,我们就可以把几个类共有的代码,抽取到一个切片中,等到需要时再切入对象中去,从而改变其原有的行为。
      这样看来,AOP其实只是OOP(Object Oriented Programming面向对象编程)的补充而已。OOP从横向上区分出一个个的类来,而AOP则从纵向上向对象中加入特定的代码。有了AOP,OOP变得立体了。如果加上时间维度,AOP使OOP由原来的二维变为三维了,由平面变成立体了。从技术上来说,AOP基本上是通过代理机制实现的。
      AOP在编程历史上可以说是里程碑式的,对OOP编程是一种十分有益的补充。
  • 相关阅读:
    Codeforces 1037D【BFS】
    hdu 4725 The Shortest Path in Nya Graph 【拆点】+【最短路】
    LightOJ 1074
    POJ1062昂贵的聘礼(经典) 枚举区间 +【Dijkstra】
    POJ 3159 Candies 【差分约束+Dijkstra】
    POJ 3126 Prime Path【BFS】
    ZOJ 1940 Dungeon Master【三维BFS】
    POJ 3279 Fliptile (二进制枚举)
    HDU 2612 find a way 【双BFS】
    POJ 3414 Pot (输出路径)【BFS】
  • 原文地址:https://www.cnblogs.com/wangcp-2014/p/8023908.html
Copyright © 2020-2023  润新知