前言
作為從事java開發的碼農，Spring的重要性不言而喻，你可能每天都在和Spring框架打交道。Spring恰如其名的，給java應用程序的開發帶了春天般的舒爽感覺。Spring，可以說是任何一個java開發者通往技術高階的必備基礎。當然，要學好Spring，尤其是了解Spring的底層原理并不容易，需要花費很多時間和精力來潛心的研習，并在實際的項目中不斷的試錯和總結，才能形成屬于自己的思維理解。博主對Spring最初的認識頗淺，項目中遇到問題依靠度娘大概也能籠而統之的解決。不過呢，接觸Spring這么一年多時間里，對其框架體系認知比較雜亂，深層技術依然是霧里看花一般，沒有形成自己的認知和理解，這對編程技術的提升是十分不利的。鑒于此，才決定靜下心來從頭至尾系統的學習Spring框架，并通過博客的形式記錄學習點滴，分享技術知識，算是拋磚引玉吧。好了，閑言少敘，咱們開始切入正題——
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方法注入等等。說到這里，你對依賴注入應該有比較直白的認知了。至于為什么要依賴注入，上文已經說得很明白了，就是為了減少代碼中組件之間的耦合度，我們還是先通過簡單示例來直觀感受下依賴注入比自己管理對象的好處吧——
|
1
2
3
4
5
6
7
8
9
10
11
12
|
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車，那么老司機想開奔馳怎么辦呢，你讓他重新創建奔馳車的對象嗎？這樣高度耦合的代碼似乎是毫無辦法的，那么，我們通過注入對象的方式對上述代碼做一番改進：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
public class Man implements Human { private Car car; public Man(Car car) { this.car = car; } @Override public void xiabibi() { } public void driveCar() { car.drive(); }} |
以上代碼根據多態特性，通過構造器接口注入的方式屏蔽掉了具體的對象實現，這樣，老司機就能想開什么車就開什么車了。這就是依賴注入帶來的好處。
AOP(Aspect Oriented Programming),面向切面編程。日常開發中，我們在完成某個業務功能的時候，寫了一堆代碼，到最后代碼優化的時候發現，真正完成業務的代碼可能就那么兩句，而其余都是與該部分業務相關度不大，僅僅是為了實現某種技術的代碼，是完全可以抽離出去的，于是很自然的，我們會將其抽取成一個工具類，這樣凡是用到的地方只需調用一下工具方法就ok了。我們再站高一點看，各個業務模塊的功能組件中除了完成相關的業務功能外，都有涉及日志、事務、安全控制等額外的操作等。這些并不是模塊的核心功能，卻又不可或缺。如果將這些額外功能添加進代碼，業務系統每個組件都來一套又顯得太過重復，而且讓業務代碼顯得混亂，不夠純粹。這個時候，你問上帝，可不可以讓你的業務代碼只專注于業務的實現，不去管什么日志、事務等不相干的東西？喔，上帝說沒問題，于是就有了AOP。如果說依賴注入的目的是讓相互協作的組件保持一種較為松散的耦合狀態的話，AOP則是將遍布應用各處的功能分離出來形成可重用的組件。通俗點說，日志、事務等都是可以重用的組件，我們完全可以將分散于業務代碼各處的日志、事務、安全等功能代碼抽離出成為一個單獨的工具組件，在Spring的配置中將其進行聲明為一個功能切面，再告訴Spring你想在哪些地方、什么時機使用（切入）這些可重用組件就行了。這就是我對面向切面的簡單釋義。該篇只是引子，所以博主就只是簡單闡述一下概念，不做具體的代碼、配置實現，在會在后續的博文中將陸續奉上，歡迎拍磚。
原文鏈接：https://www.cnblogs.com/chenbenbuyi/p/7470834.html
