ioc (inversion of control)，意為控制反轉，是spring框架的核心。但是它不僅僅是一種技術，更多的角色扮演著一種設計思想，也有人把它當做一種設計模式來對待。我檢視了很多前輩大牛的部落格，再加上自己的itoo中使用的一點經驗，寫一下自己對ioc的理解。
個人覺得ioc的前世今生一切玄奧都在「控制反轉」這四個字上。理解好」控制「和」反轉「也就是了解ioc這一設計思想了。首先，我舉個小例子來說明下，方便大家理解。
場景一：吃自助。
a：顧客
b：同伴
c：服務員
a：「我想吃烤鴨」。
c：「......」（微笑不語）。
b：「想吃烤鴨，自己去拿」。
自助相信大家都不陌生，吃自助最大的特點就是「自助」，也就是自取，想吃什麼，自己去拿什麼。不去拿，就吃不著。
場景二：吃迴轉火鍋。
a：顧客
b：同伴
c：服務員
a：「我想吃烤鴨」。
c：「......」（微笑不語）。
b：「等會兒，一會就轉過來了！」。
通過這兩個例子，我結合「控制」和「反轉」講一下自己的理解。這兩個場景包含了三個特性「烤鴨」「顧客」「是否動腳」，分別代表「依賴的物件」「main程式」「是否例項化」。場景一是沒有採用ioc設計思想的寫法，既顧客想吃烤鴨，得自己親自去取，不取就吃不到。這個親自去取的過程就可以理解為」控制「（main程式設計師能不能使用到依賴的物件，完全取決於是否例項化，也被稱為正轉）。而場景二就不同了，顧客想吃什麼，不用去取，等烤鴨迴轉到面前，就可以吃了。既顧客親自去取的「控制」被迴轉的機制取代了。換句話說，顧客能不能吃到烤鴨的控制權不在自己身上了（原來需要動動腳就可以了，現在需要等烤鴨迴轉到面前才可以），這就是」控制反轉「。
拿經典的三層來舉例，u層呼叫b層的方法，首先需要在u層例項化b層，才可以呼叫方法，這是傳統的方式。雖然功能能實現，但是問題也留了下來，1.在u層例項化b層的物件，導致u層大大依賴了b層，增加了兩者的耦合度。2.在u層例項化的物件是有生命週期的，如何銷毀和何時銷毀是個問題。
但是採用ioc思想就不同了，同樣u層呼叫b層方法，ioc的思想是將例項化的過程（暫時這樣理解）放到乙個容器裡，當u層呼叫b層的物件方法時，容器會適時地給u層提供這個物件方法。這樣的好處是u層不用去例項化b層就可以使用b層物件的方法，更不用說什麼去維護b層物件的生命週期了。
ioc (控制反轉)其實就是脫胎於傳統的呼叫方法。傳統裡是由主程式去控制物件的是否例項化，但是ioc卻剝奪了主程式這個權利，由容器去給主程式提供例項化的物件。
從0到1搭建自助分析平台
自助分析平台是構建在大資料平台之上的，依託於大資料平台的資料研發能力，通過統一的資料服務，實現對資料查詢 分析的統一管理，為企業業務分析提供高效的資料決策支援，同時也避免資料工程師陷入繁雜的提數需求中。自助分析平台是有計算機基礎的業務人員能夠快速上手的前端產品，既要有大資料的處理效能，有需要有簡單好...
自助法和蒙特卡羅
蒙特卡羅 用發射隨機數的方法模擬資料，根據模擬1000次之後得到的結果 由於隨機數是正態分佈的，要用mvrnorm方法模擬隨機數。勾mass package alpha c for i in 1 1000 mean alpha var alpha sqrt var alpha se standerr...
Spring應用級學習 從Ioc開始
spring前面一陣已經有了很多次的使用，為了解決前一陣專案中的種種疑惑，開始 應用層面 的學習。基本注入方式很簡單，包括 id是 ioc 容器中 bean 的唯一標識，命名規則需要滿足 xml 的規定 以字母開頭後面跟完整結束符 full stops name為 bean 的名字，沒有字元限制。可...