ioc，（inverse of control）控制反轉，其包含兩個內容：其一是控制，其二是反轉。在程式中，被呼叫類的選擇控制權從呼叫它的類中移除，轉交給第三方裁決。這個第三方指的就是spring的容器。ioc另解，依賴注入（dependency injection），呼叫類對被呼叫類的依賴關係由第三方注入，以移除呼叫類對被呼叫類的引用。生活中的spring ioc解析
說到租房子這件事的時候猛然間就想到了spring，類似58同城之類的發布資訊的**不就是spring裡面的容器麼。**上有很多別人提供的可以選擇的房子（bean），你所需要做的就是在沒有租房子之前想好自己的要求，比如得能洗澡，能做飯，冬暖夏涼，距離上班的地方近（這儼然就是乙個定義介面的過程），然後去網上檢索尋找合適自己的房子，前提是房東已經主動的將**資訊公布到網上（公布**資訊的過程就是將bean放入容器的過程，我們尋找房子的過程就類似於spring中注入的過程，至於是直接注入還是jndi注入，道理都是一樣的，具體方式不一樣而已）。找到房子了也就是注入成功了，找不到那只能丟擲異常嘍。宗旨就是：只要條件滿足，房子可以隨便換（只要實現了介面，具體注入哪個實現類無關緊要）
基於有向圖的spring ioc解析
從守巨集提到聊面試題當中還是學到一些比較有意思的東西，比如：spring的數學原理----有向圖。且不說這個論點對與不對，單就spring和有向圖這兩個與「資訊與計算科學」專業息息相關的知識點來看，這個論題也是值得自己好好想想的，下面就說說筆者對這句話的理解。
為了方便敘述我們把spring管理的每乙個bean當做乙個節點（假設有n個bean，那麼就有n個節點），於是這些bean加上相互之間表示呼叫關係的有向邊就組成了乙個有向圖。毫無疑問，有向圖的邊越多那麼平均來說每個頂點之間的耦合度就越大，最大的情況為完全有向圖，即任何兩個節點之間都有兩條有向邊，此時每個頂點的度為2（n-1），也就是說每個bean與其他的n-1個bean有耦合，而且還是雙向耦合。如下圖所示（這裡n=3）
眾所周知，程式設計的過程中我們總是強調高內聚、低耦合，要想達到完全的無耦合（如下圖）是不可能的。所以最優情況是保持一種松耦合的狀態，即在保證實現功能的前提下儘量減少類之間的耦合。我們可以利用介面達到這一目的，通過不同的實現類讓呼叫方對具體實現不再關心，從而達到松耦合的目的。
但是無論耦合多麼「鬆散」具體的實現類還是需要new出來的，於是就得考慮這個new的過程應該放在**才是最合適的。如果在每個bean中都去new這個bean需要的其他bean，那麼耦合的程度又回到了第一幅圖的情況，那是沒有意義的。聰明的讀者一定想到了如何解決這個問題：找乙個中間人，在中間人那裡實現new的過程，然後把new好的例項傳遞給需要這個例項的物件。這樣的話一切問題就迎刃而解了，最終的效果如圖所示
上圖也就是spring的數學描述，圖中很清晰的表明了在使用spring之後，任意兩個節點（bean）之間的有向線段變成了0（確切的說不完全是0，因為任意兩個節點之間還是可以通過容器連線的），唯一和這些bean有關係的是容器（無論誰需要什麼東西都去找容器，盡量避免兩個bean之間直接打交道）也正因為如此spring才達到了解耦的目的。
所以說，上面提到的「spring的數學原理是根據有向圖而來」這句話是有一定道理的。換個角度去看計算機，從生活，數學或者其他方面也許能把計算機看的更清楚。
文章**技術大牛郗曉勇
Spring IOC 依賴注入 控制反轉 概念理解
假設a元件依賴b元件 1.自己new乙個。主動 2.找工廠去要乙個。主動。3.等，等容器為我們提供乙個被依賴元件。被動。傳統模式下，無論是a去new乙個b元件，還是通過工廠去獲取b元件，都要需要a元件主動去獲取被依賴的b元件。用了spring之後，spring容器會負責把被依賴的b元件注入到a元件中...
學習Spring IOC控制反轉和DI依賴注入總結
30歲的小曹，20歲的身體，還在堅持在能力允許控制範圍內22點睡覺，5點起床鍛鍊身體，好好學習，除了加班或者像今天這樣的深夜，再一次寫已經有x百萬人寫過的 spring ioc 的總結部落格。一 ioc 控制反轉詳解 1 傳統非spring管理時候的物件間呼叫依賴 我們都知道，隨便一本破框架的破書上...
Spring IoC（控制反轉）
在spring中ioc 控制反轉 是通過使用di 依賴注入 設計預設實現的，那麼什麼是依賴注入呢，所謂依賴注入即是指將呼叫類對介面實現類的依賴關係由第三方注入，取消呼叫類對介面實現類的依賴關係。通過乙個簡單的例子來幫助我們理解依賴注入。首先定義乙個介面，裡面只有乙個quizmaster方法 pack...