IoC/DIP其實是一種管理思想
關(guān)于IoC的的概念提出來已經(jīng)很多年了，其被用于一種面象對像的設(shè)計。我在這里再簡單的回顧一下這個概念。我先談技術(shù)，再說管理。
話說，我們有一個開關(guān)要控制一個燈的開和關(guān)這兩個動作，最常見也是最沒有技術(shù)含量的實現(xiàn)會是這個樣子：
然后，有一天，我們發(fā)現(xiàn)需要對燈泡擴展一下，于是我們做了個抽象類：
但是，如果有一天，我們發(fā)現(xiàn)這個開關(guān)可能還要控制別的不單單是燈泡的東西，我們就發(fā)現(xiàn)這個開關(guān)耦合了燈泡這種類別，非常不利于我們的擴展，于是反轉(zhuǎn)控制出現(xiàn)了。
就像現(xiàn)實世界一樣，造開關(guān)的工廠根本不關(guān)心要控制的東西是什么，它只做一個開關(guān)應(yīng)該做好的事，就是把電接通，把電斷開（不管是手動的，還是聲控的，還是光控，還是遙控的），而我們的造各種各樣的燈泡（不管是日關(guān)燈，白熾燈）的工廠也不關(guān)心你用什么樣的開關(guān)，反正我只管把燈的電源接口給做出來，然后，開關(guān)廠和電燈廠依賴于一個標準的通電和斷電的接口。于是產(chǎn)生了IoC控制反轉(zhuǎn)，如下圖：
所謂控制反轉(zhuǎn)的意思是，開關(guān)從以前的設(shè)備的專用開關(guān)，轉(zhuǎn)變到了控制電源的開關(guān)，而以前的設(shè)備要反過來依賴于開關(guān)廠聲明的電源連接接口。只要符合開關(guān)廠定義的電源連接的接口，這個開關(guān)可以控制所有符合這個電源連接接口的設(shè)備。也就是說，開關(guān)從依賴設(shè)備這種情況，變成了，設(shè)備反過來依賴于開關(guān)所定義的接口。
只要你看過我的那篇《面向?qū)ο笤O(shè)計其實和面象對象一點關(guān)系也沒有》，你就知道這樣的例子在生活中太多見了。比如說：
1）在交易的過程中，賣家向買家賣東西，一手交錢一手交貨，所以，基本上來說賣家和買家必需強耦合（必需見面）。這個時候，銀行出來做擔(dān)保，買家把錢先墊到銀行，銀行讓賣家發(fā)貨，買家驗貨后，銀行再把錢打給賣家。這就是反轉(zhuǎn)控制。買賣雙方把對對方的直接控制，反轉(zhuǎn)到了讓對方來依賴一個標準的交易模型的接口。股票交易也是一樣的，證交所就是買賣雙方的標準交易模型接口。
2）上面這個例子，可能還不明顯，再舉一個例子。海爾公司作為一個電器制商需要把自己的商品分銷到全國各地，但是發(fā)現(xiàn)，不同的分銷渠道有不同的玩法，于是派出了各種銷售代表玩不同的玩法，隨著渠道越來越多，發(fā)現(xiàn)，每增加一個渠道就要新增一批人和一個新的流程，嚴重耦合并依賴各渠道商的玩法。實在受不了了，于是制定業(yè)務(wù)標準，開發(fā)分銷信息化系統(tǒng)，只有符合這個標準的渠道商才能成為海爾的分銷商。讓各個渠道商反過來依賴自己標準。反轉(zhuǎn)了控制，倒置了依賴。
可見，控制反轉(zhuǎn)和依賴倒置不單單的一種設(shè)計模式，反而更是一種管理模式。
在大公司中，有很多很多的團隊，這些團隊開發(fā)的軟件有很多依賴，跨團隊合作是一件挺麻煩的事情，下面是一些比較真實的示例：
1）一個網(wǎng)頁會有很多頻道，于是，我們的前端工程師進入到各個頁面為各種頻道開發(fā)他們的頁面，隨著頻道越來越多，前端開發(fā)工程師的人數(shù)也越來越多，每增加一個頻道，就要增加一個為這個頻道服務(wù)的前端團隊，于是，人數(shù)越來越多，干成了勞動密集型。為什么不反轉(zhuǎn)控制，倒置依賴呢？前端的同學(xué)完全可以開發(fā)出各種頁面的標準組件，布局，模板，以前與后端交互框架，然后，讓后端的同學(xué)反過來依賴于前端的標準，使用前端的框架，前端的布局，模板，和組件，以向前端接入后端的模塊。
2）一個平臺需要接入各種各樣的業(yè)務(wù)系統(tǒng)，這些垂直業(yè)務(wù)系統(tǒng)都有自己的賬號體系，于是這個平臺為了要兼這些垂直系統(tǒng)的賬號體系以做到權(quán)限控制，需要做各個系統(tǒng)和自己系統(tǒng)中的賬號映射，并為賬號和分配出來的資源設(shè)置各垂直系統(tǒng)的標識，還要在自己的代碼中要寫很多很多的依賴于各種賬號體系的代碼。其實，一個依賴倒置和反轉(zhuǎn)控制就很簡單。開發(fā)一個權(quán)限體系標準，讓接入方的賬號系統(tǒng)反過來依賴并控制這個標準的權(quán)限系統(tǒng)，從而做出一個干凈的系統(tǒng)。
3）還有一個云平臺中的管理模式，一些底層服務(wù)的開發(fā)團隊只管開發(fā)底層的技術(shù)，然后什么也不管了，就交給上層的開發(fā)人員，在底層團隊的開發(fā)出來的產(chǎn)品上面開發(fā)各種管理這個底層資源的東西，比如：生產(chǎn)底層資源的業(yè)務(wù)，底層資源的控制臺，底層資源的監(jiān)控系統(tǒng)。這個讓底層團隊只干純技術(shù)，不干與底層技術(shù)無關(guān)的東西，看似很科學(xué)，其實是做錯了。因為，上層為各個云資源控制生產(chǎn)，開發(fā)控制臺和監(jiān)控的團隊，隨著接入的資源的越來越多，完全干不過來了，苦逼得一塌糊涂，因為底層的資源千差百怪，每接一個就要開發(fā)一堆這個產(chǎn)品的代碼。這個時候依賴倒置和反轉(zhuǎn)控制又可以解決問題了。很簡單，上層為各個云資源控制生產(chǎn)，開發(fā)控制臺，和監(jiān)控的團隊應(yīng)該制定一個標準，讓底層的IaaS云資源開發(fā)團隊反過來依賴這個標準，統(tǒng)一接入方式，如果開發(fā)的云資源不符我的生產(chǎn)控制模型，沒有控制臺，不把監(jiān)控數(shù)據(jù)喂入我的監(jiān)控系統(tǒng)，對不起，請不要接入我這個PaaS平臺。
4）一個集中式的處理電子商務(wù)中的訂單的流程。各個垂直業(yè)務(wù)線都需要通過這個平臺來處理自己的訂單流程，但是垂直業(yè)務(wù)線上的個性化需求太多。于是，這個技術(shù)平臺開始出現(xiàn)了黑魔法——“為了害怕改變數(shù)據(jù)庫表結(jié)構(gòu)，不得不在數(shù)據(jù)庫中預(yù)留一些字段，里面存把業(yè)務(wù)方的個性化字段存成如JSON這樣的東西”，并為之自豪認為可以快速解決業(yè)務(wù)問題（WTF）。然而，惡夢并沒就此結(jié)束，管理這個技術(shù)平臺的小組開始發(fā)現(xiàn)，對來自各個業(yè)務(wù)方的需求應(yīng)接不暇，各種變態(tài)需求嚴重干擾系統(tǒng)，各種技術(shù)決定越來越不好做，導(dǎo)致需求排期排不過來。于是，不單單得到了各個業(yè)務(wù)方的各種抱怨，最可怕的是還有高層老大們壓過來的Deadline，加班加點，苦逼之極。為什么不用依賴倒置和反轉(zhuǎn)控制的思想呢？開發(fā)一個插件模型、工作流引擎和Pub/Sub系統(tǒng)，讓業(yè)務(wù)方的個性化需求可以以插件的方式插入我的訂單流程中，業(yè)務(wù)方自的數(shù)據(jù)存在自己的庫中，業(yè)務(wù)邏輯也不要侵入我的系統(tǒng)，并可以使用工作流引擎或Pub/Sub的協(xié)義標準來自己定義工作流的各個步驟（甚至把工作流引擎的各個步驟的Decider交給各個業(yè)務(wù)方自行處理）。讓各個業(yè)務(wù)方來依賴于我的標準插件和工作流接口，反轉(zhuǎn)迭控制，讓他們來控制我的系統(tǒng)，依賴倒置，讓他們來依賴我的標準。（這個團隊想過把自己的系統(tǒng)內(nèi)部開源出去讓別的團隊也進來參與，可以是可以，但一定要用Linux/Git這種方式，允許出現(xiàn)多個分支，多個發(fā)行版。但多個版本又和業(yè)務(wù)相違背）
5）看過《SteveY對Amazon和Google平臺的吐槽》的人都知道，Amazon內(nèi)部系統(tǒng)的SOA架構(gòu)（這個SOA架構(gòu)離IBM定義的那個非常變態(tài)的SOA還有一定距離），但是這基本上都是依賴倒置和控制反轉(zhuǎn)的思路了—— 與其讓我來幫你實現(xiàn)你的業(yè)務(wù)邏輯，不如把我的業(yè)務(wù)邏輯開放成服務(wù)的方式讓你來控制。
6）再說一個我在Amazon經(jīng)歷的例子。有一個項目是在給Amazon的各個商區(qū)（Marketplace）做國際出口的業(yè)務(wù)，我們先把Media類的產(chǎn)品（書，DVD之類的）做國際出口開放，項目不難，就是讓商家同意一個法律協(xié)議（上傳自己的簽名），然后后臺小改一下。美國的，歐洲的做的都沒有問題，物流團隊在出口報關(guān)單上打的都是Amazon倉庫的地址和商家的簽名（本來這就是錯的，打的應(yīng)該是商家的地址和商家的簽名），但是到了日本，就出了問題，因為日本海關(guān)即要日文信息，也要商家的英文名和英文地址，而我們的系統(tǒng)里面只有商家的日文信息。本來，這是一個挺簡單的事——數(shù)據(jù)庫里加兩個字段，在那個同意條款的網(wǎng)頁上收集一下商家的英文名和地址，然后把這些信息傳給后面的物流團隊。物流團隊一看這個，發(fā)現(xiàn)搞不了，因為他還要傳給倉庫，N多的地方都要加這兩個字段，還要寫下各種if (site == JP)這樣的判斷。物流團隊不蠻干，重新設(shè)計自己的系統(tǒng)。做一個Document Template的東西，這個就是那個那個要貼在物流盒子上的單子。再也不讓各個業(yè)務(wù)團隊把那些信息傳過來，而是把這個Document Template的東西傳給上面的業(yè)務(wù)方，他們想怎么寫就怎么寫， 寫完后，把這個東西傳回來。于是，大家依賴了一個標準的協(xié)議，而不是一其字段。（當然，這個改動過多，為此改了半年多，不過非常值）
所以說啊，在跨團隊的工作中，
- 如果依賴和控制的東西過多了，就需要制定標準，倒置依賴，反轉(zhuǎn)控制。
- 控制欲望***不要太強，不要想著能干所有的事情，要學(xué)會控制反轉(zhuǎn)和依賴倒置原則。否則只會引火燒身。
- 反轉(zhuǎn)控制和依賴倒置是一種智慧。
