本文中di指依賴倒置。
依賴的概念
baidu百科：依靠別人或事物而不能自立或自給。
軟體開發中的依賴：依賴描述了兩個模型元素之間的關係，如果被依賴的模型元素發生變化就會影響到另乙個模型元素。
di的概念
a. 上層模組不應該依賴於下層模組，它們共同依賴於乙個抽象。
b. 抽象不能依賴於具象，具象依賴於抽象。
例項談開
在分層開發中，通常會有這樣的兩個模組：dal（資料訪問層)和bll(業務邏輯層) 。 下面就以電子商務系統中的 訂單、產品、使用者 為例來說說這兩個模組之間的依賴關係。
正向依賴
dal：
public
class
orderdao
public
list
<
orders
>
getorderbyproductid(
intproductid)}
bll：
public
class
order
public
list
<
orders
>
getorderbyuserid (
intuserid)
public
list
<
orders
>
getorderbyproductid(
intproductid)}
bll中order持有了dal中orderdao的引用，這個時候bll模組依賴於dal模組。他們之間構成了緊耦合。如果要更換dal模組，顯然需要修改bll中的**。
引入抽象
依賴倒置的思想告訴我們上層模組（bll）和下層模組（dal）都應當依賴於抽象。那麼我們引入乙個抽象模組。
抽象模組：
public
inte***ce
iorderdao
dal：
public
class
orderdao:iorderdao//
繼承於抽象
public
list
<
orders
>
getorderbyproductid(
intproductid)}
bll：
public
class
order
public
list
<
orders
>
getorderbyuserid(
intuserid)
public
list
<
orders
>
getorderbyproductid(
intproductid)}
現在bll持有了對抽象模組的引用，而dal也依賴於該抽象模組。抽象模組的引入消除了bll和dal之間的依賴。那麼這種方法是否完美呢？
介面的單一性
在乙個業務驅動的系統中，如果與訂單相關的業務發生變化，會導致我們去修改 iorderdao ，相應的dal中的orderdao 和bll的order都會被修改。
什麼原因呢？
上面的這種設計讓我們無法保持乙個穩定的介面。物件導向設計中，有這樣的兩個原則：
單一職責原則(srp)：保證物件的細粒度和單一性。
開放-封閉原則(ocp)：對於擴充套件開放，對於更改封閉。
於是有了下面的設計。
抽象模組：
public
inte***ce
iorderuserdao
public
inte***ce
iorderproductdao
dal：
public
partial
class
orderdao:iorderuserdao
}public
partial
class
orderdao:iorderproductdao}
bll：
public
class
user
public
list
<
orders
>
getorderbyuserid(
intuserid)
}public
class
product
public
list
<
orders
>
getorderbyproductid(
intproductid)}
那麼您的意見呢？
談談我對Spring IOC與DI的理解
ioc是一種叫做 控制反轉 的設計思想。1 較淺的層次 從名字上解析 控制 就是指對 物件的建立 維護 銷毀等生命週期的控制，這個過程一般是由我們的程式去主動控制的，如使用new關鍵字去建立乙個物件 建立 在使用過程中保持引用 維護 在失去全部引用後由gc去 物件 銷毀 反轉 就是指對 物件的建立 ...
談談我對bloom filter的理解。
我們都看過封神榜吧，每乙個神位都對應著乙個人。在西周時代，如果乙個人聲稱自己是神，那麼他必須可以通過封神榜的驗證，如果封神榜驗證了下這個人，發現神位上根本沒這號人，那麼這個人絕對不是神。但是封神榜的驗證方式是有漏洞的，那些企圖依靠神的名聲招搖撞騙的人之中，有些人發現了這個秘密，他們可以通過偽造自己的...
談談我對flexbox的理解
寫在開頭 關於flex，學了很久的前端了，偶爾也在用，尤其是當需要水平居中的時候，就用display flex，感覺非常好用。但是其實對於flex的理解並不是很到位，根本都不懂flex，所以正兒八經的來研究一下flexbox。flex布局模型不同於塊和內聯模型布局，塊和內聯模型的布局計算依賴於塊和內...