IoC(控制反轉)

　　IoC（Inversion of Control，控制反轉）是spring的核心，貫穿始終。所謂IoC，對於spring框架來說，就是由spring來負責控制對象的生命周期和對象間的關系。所有的類都會在spring容器中登記，告訴spring你是個什麽東西，你需要什麽東西，然後spring會在系統運行到適當的時候，把你要的東西主動給你，同時也把你交給其他需要你的東西。所有的類的創建、銷毀都由 spring來控制，也就是說控制對象生存周期的不再是引用它的對象，而是spring。對於某個具體的對象而言，以前是它控制其他對象，現在是所有對象都被spring控制，所以這叫控制反轉。

DI(依賴註入)

　　IoC的一個重點是在系統運行中，動態的向某個對象提供它所需要的其他對象。這一點是通過DI（Dependency Injection，依賴註入）來實現的。比如對象A需要操作數據庫，以前我們總是要在A中自己編寫代碼來獲得一個Connection對象，有了 spring我們就只需要告訴spring，A中需要一個Connection，至於這個Connection怎麽構造，何時構造，A不需要知道。在系統運行時，spring會在適當的時候制造一個Connection，然後像打針一樣，註射到A當中，這樣就完成了對各個對象之間關系的控制。A需要依賴 Connection才能正常運行，而這個Connection是由spring註入到A中的，依賴註入的名字就這麽來的。

對IoC(控制反轉)和DI(依賴註入)的理解

　　在平時的java應用開發中，我們要實現某一個功能或者說是完成某個業務邏輯時至少需要兩個或以上的對象來協作完成，在沒有使用Spring的時候，每個對象在需要使用他的合作對象時，自己均要使用像new object() 這樣的語法來將合作對象創建出來，這個合作對象是由自己主動創建出來的，創建合作對象的主動權在自己手上，自己需要哪個合作對象，就主動去創建，創建合作對象的主動權和創建時機是由自己把控的，而這樣就會使得對象間的耦合度高了，A對象需要使用合作對象B來共同完成一件事，A要使用B，那麽A就對B產生了依賴，也就是A和B之間存在一種耦合關系，並且是緊密耦合在一起，而使用了Spring之後就不一樣了，創建合作對象B的工作是由Spring來做的，Spring創建好B對象，然後存儲到一個容器裏面，當A對象需要使用B對象時，Spring就從存放對象的那個容器裏面取出A要使用的那個B對象，然後交給A對象使用，至於Spring是如何創建那個對象，以及什麽時候創建好對象的，A對象不需要關心這些細節問題(你是什麽時候生的，怎麽生出來的我可不關心，能幫我幹活就行)，A得到Spring給我們的對象之後，兩個人一起協作完成要完成的工作即可。

面向對象的五大基本原則
單一職責原則（SRP）
開放封閉原則（OCP）
裏氏替換原則（LSP）
依賴倒置原則（DIP）
接口隔離原則（ISP）

單一職責原則（SRP）

? 一個類應該僅有一個引起它變化的原因(最簡單，最容易理解卻最不容易做到的一個設計原則)
職員類例子：
比如在職員類裏，將工程師、銷售人員、銷售經理這些情況都放在職員類裏考慮，其結果將會非常混亂，在這個假設下，職員類裏的每個方法都要if else判斷是哪種情況，從類結構上來說將會十分臃腫，並且上述三種的職員類型，不論哪一種發生需求變化，都會改變職員類！這個是大家所不願意看到的！

開放封閉原則（OCP）

? 既開放又封閉，對擴展是開放的，對更改是封閉的！

? 擴展即擴展現行的模塊，當我們軟件的實際應用發生改變時，出現新的需求，就需要我們對模塊進行擴展，使其能夠滿足新的需求！

更改封閉即是在我們對模塊進行擴展時，勿需對源有程序代碼和DLL進行修改或重新編譯文件！

這個原則對我們在設計類的時候很有幫助，堅持這個原則就必須盡量考慮接口封裝，抽象機制和多態技術！

裏氏替換原則（LSP）

? 子類可以替換父類並且出現在父類能夠出現的任何地方

? 這個原則也是在貫徹GOF倡導的面向接口編程！
在這個原則中父類應盡可能使用接口或者抽象類來實現！

子類通過實現了父類接口，能夠替父類的使用地方！
通過這個原則，客戶端在使用父類接口的時候，通過子類實現！
意思就是說依賴父類接口，在客戶端聲明一個父類接口，通過其子類來實現
這個時候就要求子類必須能夠替換父類所出現的任何地方，這樣做的好處就是，在根據新要求擴展父類接口的新子類的時候而不影響當前客戶端的使用！

依賴倒置原則（DIP）

? 傳統的結構化編程中，最上層的模塊通常都要依賴下面的子模塊來實現，也
稱為高層依賴低層！
所以DIP原則就是要逆轉這種依賴關系，讓高層模塊不要依賴低層模塊，所以稱之為依賴倒置原則！

ISP 接口隔離原則

? 這個原則的意思是：使用多個專門的接口比使用單個接口要好的多！

實際編程中，為了減少接口的定義，將許多類似的方法都放在一個接口中，最後發現，維護和實現接口的時候花了太多精力，而接口所定義的操作相當於對客戶端的一種承諾，這種承諾當然是越少越好，越精練越好，過多的承諾帶來的就是你的大量精力和時間去維護！

ioc以及面向對象五大原則