對於解耦的理解

以三層為例子：

在bll層中建立dal層的某個物件

iuserdal userdal = dalabstractfactory.createuserdal();

即層之間的關聯降到最低，這樣我們很容易想到引用乙個第三方來作為中間介質。

這就引出了介面，在層中要建立其他層的某個物件時，用介面來接收這個物件，（這個介面是這個物件的介面，如物件為userdal，介面為iuserdal）

這就實現了等式左邊與dal層的解耦，關於右邊，我們不能直接建立該物件的例項。這樣還是耦合，所以引入工廠的概念，

實質還是通過乙個第三方來幫我們進行這個動作，即建立物件。

這樣就實現了等式兩邊均解耦。

但回過頭來想，解耦的目的是什麼？

不就是為了降低**的維護成本與可讀性嗎，可讀性先放在一邊。

那麼兩層之間是解耦了，但在工廠中是直接建立物件的，雖然**很少，只是建立物件，但專案一大，有很多物件，依然維護起來很麻煩。

我們想，有個什麼辦法把工廠裡建立物件這個動作也給封裝下呢，使到時候要修改的時候，修改一小塊地方就可以了。

於是，我們想到了利用配置檔案

然後利用反射（assembly）來引導程式集，與建立物件。

其實就是將我們本來在工廠中手動的兩動作（新增dll引用+new乙個物件）變成了動態的了。

我們將這個工廠模式稱為抽象工廠。

小結：解耦，說白了就是當使用者的需求發生變化時，作為一線勞動力的我們，為自己在維護**時省麻煩，於是在一開始設計框架的時候，設計的好一點，這個好估計是當初那麼一代代程式設計師掉坑爬出來後的精神感悟吧。

然後再關注下**本身，將物件導向的特性展現了一大部分。即繼承，封裝，多型。這裡只是一小部分，框架的建設就是圍繞這個特性展開的。不過有一點是這樣的，個人的一點體會：不是為了用到這些特性，將他們放到框架中，

而是為了更好的框架建立，而需要用到這些特性，所以才有了這些特性，才被我們在使用。

有什麼不合適之處請大夥兒指出，共同進步。