深入了解Spring底層原理-IOC

一、概述

  • Spring是一個輕量級的開源JavaEE框架
  • Spring可以解決企業(yè)應(yīng)用開發(fā)的復雜性
  • Spring兩大核心部分:IoC和AOP
    特點:
  • 方便解耦,簡化開發(fā)
  • AOP編程支持
  • 方便程序測試
  • 方便和其他框架整合
  • 方便事務(wù)操作
  • 降低API開發(fā)難度

IoC和AOP是Spring的核心,分析其原理:
二、IoC解耦推導

  • 我們都知道,IoC是控制反轉(zhuǎn),通俗講就是把對象創(chuàng)建和對象之間的調(diào)用交給Spring管理,通過簡單的xml配置就可以創(chuàng)建和調(diào)用對象,其主要目的就是解耦,降低代碼之間的耦合度,咱們就從傳統(tǒng)方式到IoC來一步一步講述怎樣把耦合度降到最低。
  • 所謂解耦就是降低類之間的依賴和方法之間的依賴

1. 傳統(tǒng)直接調(diào)用對象

  • 在我們傳統(tǒng)的開發(fā)方式中,是直接采取new對象的方式創(chuàng)建對象,經(jīng)??梢钥吹絪ervice調(diào)用dao這樣的代碼,如果是直接調(diào)用,我們來看看是怎么樣子的,創(chuàng)建UserService和UserDao ,通過UserService調(diào)用UserDao:
// UserDao1類
public class UserDao1 {
   public void say(){
       System.out.println("I am userDao1");
   }
}

// UserService類,調(diào)用UserDao1類中的方法
public class UserService {
   public void getUser(UserDao1 userDao1){
       userDao1.say();
   }
}

在上面的代碼中,是最傳統(tǒng)的調(diào)用方式,通過service調(diào)用dao,可以得到我們想要的結(jié)果,打印出:“I am userDao1”,但是,突然,產(chǎn)品經(jīng)理想要UserDao2一個新的類也可以在UserService中進行調(diào)用,這個時候,就需要將代碼改為如下:

// UserDao1類
public class UserDao1 {
    public void say(){
        System.out.println("I am userDao1");
    }
}

// UserDao2類
public class UserDao2 {
    public void say(){
        System.out.println("I am userDao2");
    }
}


// UserService類,調(diào)用UserDao1和UserDao2類中的方法
public class UserService {
    public void getUser(UserDao1 userDao1){
        userDao1.say();
    }
    
    public void getUser(UserDao2 userDao2){
        userDao2.say();
    }
}
  • 可以看到,我們不僅要新建一個UserDao2類,還需要修改UserService中的代碼,萬一,突然,產(chǎn)品經(jīng)理想把UserDao3、UserDao4、UserDao5.....這樣具有相同功能的類也在userService中作為參數(shù)進行調(diào)用,新建這些類倒還好,避免不了,問題是還要修改UserService類,簡直頭大....
  • 其實,上面的代碼中,UserService就和要調(diào)用的dao類具有一種很強的聯(lián)系,我們把這種聯(lián)系稱為強耦合關(guān)系,這種強耦合關(guān)系是不利于開發(fā)的,因此我們需要解耦,首先想到的便是使用接口進行解耦,也就是面向接口編程。

2. 接口解耦
將上面的代碼進行修改,將UserDao定義為接口,然后去實現(xiàn)這個接口,再進行調(diào)用,如下:// UserDao接口

public interface UserDao {
    void say();
}

// 接口實現(xiàn)類UserDao1
public class UserDaoImpl1 implements UserDao {
    @Override
    public void say() {
        System.out.println("I am userDao1");
    }
}

// 接口實現(xiàn)類UserDao2
public class UserDaoImpl2 implements UserDao {
    @Override
    public void say() {
        System.out.println("I am userDao2");
    }
}


// UserService中進行調(diào)用
public class UserService {
    public void getUser(UserDao userDao){
        userDao.say();
    }
}
  • 在上面的代碼中,我們可以看到,UserService類中g(shù)etUser方法參數(shù)可以是UserDao1類型的,也可以是UserDao2類型的,不像之前的代碼,只能是指定的UserDao。這時,UserService和UserDao1、UserDao2聯(lián)系的就沒那么緊密了,這是一種弱耦合關(guān)系,通過接口來進行解耦。

  • 但是仔細查看上面的代碼,你會發(fā)現(xiàn),接口和實現(xiàn)類之間還是存在強耦合關(guān)系,在面向接口編程中,我們常常會看到類似這樣的代碼:

UserDao userDao = new UserDaoImpl1();

假設(shè)現(xiàn)在不用這個UserDaoImpl1了,而改用UserDao的另一個實現(xiàn)類UserDaoImpl2,代碼就要改為如下:

UserDao userDao = new UserDaoImpl2();
  • 這樣也就是接口和實現(xiàn)類出現(xiàn)了耦合,為了進一步解耦,我們就使用下面的工廠模式。

3. 工廠模式解耦

  • 工廠的意思也就是一個批量制造同樣規(guī)格(規(guī)格也就是接口類所提供好的規(guī)范)類的類,所謂的工廠模式也就是將所有的創(chuàng)建對象任務(wù)交給了一個“中間人”,也就是工廠類來實現(xiàn),要想使用對象,直接找工廠類,實現(xiàn)類必須要從工廠中取出來。

而要使用工廠模式進行解耦,我們需要先將創(chuàng)建對象交給工廠類:

// 工廠類
public class BeanFactory {
    // 創(chuàng)建并返回UserDaoImpl1
    public static UserDao getUserDao1(){
        return new UserDaoImpl1();
    }

    // 創(chuàng)建并返回UserDaoImpl2
    public static UserDao getUserDao2(){
        return new UserDaoImpl2();
    }
}

將創(chuàng)建對象交給工廠類,調(diào)用關(guān)系就轉(zhuǎn)變?yōu)槿缦拢?/p>

UserDao userDao = new UserDaoImpl1();  ===>  UserDao userDao1 = BeanFactory.getUserDao1();
UserDao userDao = new UserDaoImpl2();  ===>  UserDao userDao2 = BeanFactory.getUserDao2();
  • 這樣一來,我們創(chuàng)建對象只需要調(diào)用工廠類BeanFactory中的方法即可,調(diào)用時不是直接通過接口,而是通過工廠類,將創(chuàng)建對象交給了工廠類,就降低了接口和實現(xiàn)類之間的耦合。
  • 上面的方法雖然降低了接口和實現(xiàn)類之間的耦合度,但是,這樣接口和工廠類之間就產(chǎn)生了耦合,為了再次解耦,我們引入了反射+xml配置文件的方式進行再次解耦。

4. xml 配置 + 反射 + 工廠解耦(IoC底層的實現(xiàn))
使用xml配置文件

<bean id="userDao" class="**.UserDaoImpl">

工廠類

class BeanFactory {
    public static UserDao getUserDao(String id) {
        // String className = 解析配置文件xml 拿到id對應(yīng)的class
        // 反射
        class clazz = class.forName(className);
        return clazz.newInstance();
    }
}

可以看到,在這個工廠類中,并沒有直接像上面那樣直接new對象,而是使用了xml解析和反射方式創(chuàng)建對象,分析如下:

  • 通過xml解析獲取對象中屬性的值
  • 通過反射得到字節(jié)碼文件
  • 通過字節(jié)碼文件創(chuàng)建對象

這樣的話如果我們需要改UserDao的實現(xiàn)類的類型,我們可以直接在配置文件中修改,就不需要修改代碼,這就是IoC的解耦。

三、IoC 原理理解
1. IoC是什么

  • IoC:Inversion of Control(控制反轉(zhuǎn)),這不是什么技術(shù),而是一種設(shè)計思想,在java開發(fā)中,IoC意味著將你設(shè)計好的對象交給容器,而不是傳統(tǒng)的在你的對象內(nèi)部直接控制,如何理解好Ioc呢?理解好IoC的關(guān)鍵是要明確“誰控制誰,控制什么,為何是反轉(zhuǎn)(有反轉(zhuǎn)就應(yīng)該有正轉(zhuǎn)了),哪些方面反轉(zhuǎn)了”,那我們來深入分析一下:

  • 誰控制誰,控制什么:傳統(tǒng)Java SE程序設(shè)計,我們直接在對象內(nèi)部通過new進行創(chuàng)建對象,是程序主動去創(chuàng)建依賴對象;而IoC是有專門一個容器來創(chuàng)建這些對象,即由IoC容器來控制對 象的創(chuàng)建;誰控制誰?當然是IoC 容器控制了對象;控制什么?那就是主要控制了外部資源獲?。ú恢皇菍ο蟀ū热缥募龋?br> 為何是反轉(zhuǎn),哪些方面反轉(zhuǎn)了:有反轉(zhuǎn)就有正轉(zhuǎn),傳統(tǒng)應(yīng)用程序是由我們自己在對象中主動控制去直接獲取依賴對象,也就是正轉(zhuǎn);而反轉(zhuǎn)則是由容器來幫忙創(chuàng)建及注入依賴對象;為何是反轉(zhuǎn)?因為由容器幫我們查找及注入依賴對象,對象只是被動的接受依賴對象,所以是反轉(zhuǎn);哪些方面反轉(zhuǎn)了?依賴對象的獲取被反轉(zhuǎn)了。

2. IoC能做什么

  • IoC 不是一種技術(shù),只是一種思想,一個重要的面向?qū)ο缶幊痰姆▌t,它能指導我們?nèi)绾卧O(shè)計出松耦合、更優(yōu)良的程序。傳統(tǒng)應(yīng)用程序都是由我們在類內(nèi)部主動創(chuàng)建依賴對象,從而導致類與類之間高耦合,難于測試;有了IoC容器后,把創(chuàng)建和查找依賴對象的控制權(quán)交給了容器,由容器進行注入組合對象,所以對象與對象之間是 松散耦合,這樣也方便測試,利于功能復用,更重要的是使得程序的整個體系結(jié)構(gòu)變得非常靈活。
    其實IoC對編程帶來的最大改變不是從代碼上,而是從思想上,發(fā)生了“主從換位”的變化。應(yīng)用程序原本是老大,要獲取什么資源都是主動出擊,但是在IoC/DI思想中,應(yīng)用程序就變成被動的了,被動的等待IoC容器來創(chuàng)建并注入它所需要的資源了。
      IoC很好的體現(xiàn)了面向?qū)ο笤O(shè)計法則之一—— 好萊塢法則:“別找我們,我們找你”;即由IoC容器幫對象找相應(yīng)的依賴對象并注入,而不是由對象主動去找。
    3. IoC和DI
  • DI:DI—Dependency Injection,即“依賴注入”:組件之間依賴關(guān)系由容器在運行期決定,形象的說,即由容器動態(tài)的將某個依賴關(guān)系注入到組件之中。依賴注入的目的并非為軟件系統(tǒng)帶來更多功能,而是為了提升組件重用的頻率,并為系統(tǒng)搭建一個靈活、可擴展的平臺。通過依賴注入機制,我們只需要通過簡單的配置,而無需任何代碼就可指定目標需要的資源,完成自身的業(yè)務(wù)邏輯,而不需要關(guān)心具體的資源來自何處,由誰實現(xiàn)。
      理解DI的關(guān)鍵是:“誰依賴誰,為什么需要依賴,誰注入誰,注入了什么”,那我們來深入分析一下:
  • 誰依賴于誰:當然是應(yīng)用程序依賴于IoC容器;

  • 為什么需要依賴:應(yīng)用程序需要IoC容器來提供對象需要的外部資源;

  • 誰注入誰:很明顯是IoC容器注入應(yīng)用程序某個對象,應(yīng)用程序依賴的對象;

  • 注入了什么:就是注入某個對象所需要的外部資源(包括對象、資源、常量數(shù)據(jù))。

  • IoC和DI由什么關(guān)系呢?其實它們是同一個概念的不同角度描述,由于控制反轉(zhuǎn)概念比較含糊(可能只是理解為容器控制對象這一個層面,很難讓人想到誰來維護對象關(guān)系),所以2004年大師級人物Martin Fowler又給出了一個新的名字:“依賴注入”,相對IoC 而言,“依賴注入”明確描述了“被注入對象依賴IoC容器配置依賴對象”。

  • 總之依賴注入的意思是你需要的東西不是由你創(chuàng)建的,而是第三方,或者說容器提供給你的。這樣的設(shè)計符合正交性,即所謂的松耦合。

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點,簡書系信息發(fā)布平臺,僅提供信息存儲服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容