Spring基礎篇——DI/IOC和AOP原理初識

前言

  做爲從事java開發的碼農,Spring的重要性不言而喻,你可能天天都在和Spring框架打交道。Spring恰如其名的,給java應用程序的開發帶了春天般的舒爽感受。Spring,能夠說是任何一個java開發者通往技術高階的必備基礎。固然,要學好Spring,尤爲是瞭解Spring的底層原理並不容易,須要花費不少時間和精力來潛心的研習,並在實際的項目中不斷的試錯和總結,才能造成屬於本身的思惟理解。博主對Spring最初的認識頗淺,項目中遇到問題依靠度娘大概也能籠而統之的解決。不過呢,接觸Spring這麼一年多時間裏,對框架體系認知比較雜亂,深層技術依然是霧裏看花通常,沒有造成本身的認知和理解,這對編程技術的提高是十分不利的。鑑於此,才決定靜下心來從頭到尾系統的學習Spring框架,並經過博客的形式記錄學習點滴,分享技術知識,算是拋磚引玉吧。好了,閒言少敘,我們開始切入正題——java

Spring框架核心介紹

  DI(Dependency Injection),依賴注入,和咱們常據說的另外一個概念 IOC(控制反轉)其實歸根結底實現的功能是相同的,只是一樣的功能站在不一樣的角度來闡述罷了。這裏博主就不去過多的辨析,度娘上有一大堆解釋。咱們須要知道的是,什麼叫依賴注入,爲何要依賴注入。搞清這兩點,我想對Spring的學習在思想上就算是上道了。編程

  在沒用使用Spring的時候——也就是沒有依賴注入的時候,java應用程序的類與類之間要實現相互的功能協做是比較費勁的,某個類(A)要實現它的功能若是須要依賴另外一個類(B)的協做的話,就須要在A類中主動建立出B類的對象,才能使用B類的方法完成功能(這裏看官就不要去糾結靜態方法之類的狀況了)。這等因而A類須要負責B類對象整個生命週期的管理。在極度簡單的狀況下,在一個類中new出另外一個類的對象彷佛並無什麼問題,可是複雜的應用程序類與類的協做關係每每是多邊的,咱們並不知道一個類功能的實現會依賴多少個另類對象來協做,因此在類中自行建立對象而且管理對象的整個生命週期,會形成代碼的高度耦合以及不可想象的複雜度。那麼,試想,若是咱們能將對象的生命週期交給第三方組件來管理,當某個類須要另外的對象時第三方組件就直接建立出來交給它,這樣,類就能夠只專一於本身功能的實現,而不用去管理其餘類對象的生命週期,這樣類的功能就單純了不少。是的,你必定已經明白了,Spring(容器)就是這個第三方組件。咱們只須要告訴Spring(容器)有哪些對象須要管理就好了,不用去關心Spring框架是如何建立對象的。這樣,當某個類A須要類B對象時,若是類B已經聲明交給了Sping容器管理,那麼在程序運行到類A須要類B時,Spring容器就經過依賴注入的方式,將類B對象注入到類A中協助完成業務功能。經過第三方組件的依賴注入,對象無需再自行的建立和管理類與類之間的依賴關係了。對象的建立依賴注入的方式也有多種,譬如接口注入,構造方法注入,setter方法注入等等。說到這裏,你對依賴注入應該有比較直白的認知了。至於爲何要依賴注入,上文已經說得很明白了,就是爲了減小代碼中組件之間的耦合度,咱們仍是先經過簡單示例來直觀感覺下依賴注入比本身管理對象的好處吧——安全

 

public class Man implements Human {
    private QQCar car;
    public Man() {
        this.car = new QQCar();
    }
    @Override
    public void xiabibi() {
    }
    public void driveCar(){
        car.drive();
    }
}

 

    接口Car暫有兩個實現:奔馳車和QQ車,在以上Man類和QQCar類高度耦合的代碼中,老司機經過構造器只建立了QQ車對象,因此只能開QQ車,那麼老司機想開奔馳怎麼辦呢,你讓他從新建立奔馳車的對象嗎?這樣高度耦合的代碼彷佛是毫無辦法的,那麼,咱們經過注入對象的方式對上述代碼作一番改進:框架

 

public class Man implements Human {
    private Car car;
    public Man(Car car) {
        this.car = car;
    }
    @Override
    public void xiabibi() {
    }

    public void driveCar() {
        car.drive();
    }
}

 

 以上代碼根據多態特性,經過構造器接口注入的方式屏蔽掉了具體的對象實現,這樣,老司機就能想開什麼車就開什麼車了。這就是依賴注入帶來的好處。
ide

  AOP(Aspect Oriented Programming),面向切面編程平常開發中,咱們在完成某個業務功能的時候,寫了一堆代碼,到最後代碼優化的時候發現,真正完成業務的代碼可能就那麼兩句,而其他都是與該部分業務相關度不大,僅僅是爲了實現某種技術的代碼,是徹底能夠抽離出去的,因而很天然的,咱們會將其抽取成一個工具類,這樣凡是用到的地方只需調用一下工具方法就ok了。咱們再站高一點看,各個業務模塊的功能組件中除了完成相關的業務功能外,都有涉及日誌、事務、安全控制等額外的操做等。這些並非模塊的核心功能,卻又不可或缺。若是將這些額外功能添加進代碼,業務系統每一個組件都來一套又顯得太太重複,並且讓業務代碼顯得混亂,不夠純粹。這個時候,你問上帝,可不可讓你的業務代碼只專一於業務的實現,不去管什麼日誌、事務等不相干的東西?喔,上帝說沒問題,因而就有了AOP。若是說依賴注入的目的是讓相互協做的組件保持一種較爲鬆散的耦合狀態的話,AOP則是將遍及應用各處的功能分離出來造成可重用的組件。通俗點說,日誌、事務等都是能夠重用的組件,咱們徹底能夠將分散於業務代碼各處的日誌、事務、安全等功能代碼抽離出成爲一個單獨的工具組件,在Spring的配置中將其進行聲明爲一個功能切面,再告訴Spring你想在哪些地方、什麼時機使用(切入)這些可重用組件就好了。這就是我對面向切面的簡單釋義。該篇只是引子,因此博主就只是簡單闡述一下概念,不作具體的代碼、配置實現,在會在後續的博文中將陸續奉上,歡迎拍磚。
工具

 

  2017年最後一天了,想一想這一年,除了年齡以外,技術、能力都成長的太慢太慢,博文更新太懶惰,好久憋不出點東西了,不善總結、學習,這對技術人員來講是致命的缺點。新的一年,當以此爲戒,嚴格律己,每週至少應有一篇博文總結,以此爲誓!學習

相關文章
相關標籤/搜索