以三層為例子：在Bll層中創建Dal層的某個對象IUserDal userDal = DalAbstractFactory.CreateUserDal();即層之間的關聯降到最低，這樣我們很容易想到引用一個第三方來作為中間介質。這就引出了介面，在層中要創建其他層的某個對象時，用介面來接收這個對象，（...
以三層為例子：
在Bll層中創建Dal層的某個對象
IUserDal userDal = DalAbstractFactory.CreateUserDal();
即層之間的關聯降到最低，這樣我們很容易想到引用一個第三方來作為中間介質。
這就引出了介面，在層中要創建其他層的某個對象時，用介面來接收這個對象，（這個介面是這個對象的介面，如對象為UserDal，介面為IUserDal）
這就實現了等式左邊與Dal層的解耦，關於右邊，我們不能直接創建該對象的實例。這樣還是耦合，所以引入工廠的概念，
實質還是通過一個第三方來幫我們進行這個動作，即創建對象。
這樣就實現了等式兩邊均解耦。
但回過頭來想，解耦的目的是什麼？
不就是為了降低代碼的維護成本與可讀性嗎，可讀性先放在一邊。
那麼兩層之間是解耦了，但在工廠中是直接創建對象的，雖然代碼很少，只是創建對象，但項目一大，有很多對象，依然維護起來很麻煩。
我們想，有個什麼辦法把工廠里創建對象這個動作也給封裝下呢，使到時候要修改的時候，修改一小塊地方就可以了。
於是，我們想到了利用配置文件
將對象所屬的程式集（dll）與命名空間放在配置文件的appSettings節點中，
然後利用反射（Assembly）來載入程式集，與創建對象。
其實就是將我們本來在工廠中手動的兩動作（添加dll引用+new一個對象）變成了動態的了。
我們將這個工廠模式稱為抽象工廠。
小結：
解耦，說白了就是當用戶的需求發生變化時，作為一線勞動力的我們，為自己在維護代碼時省麻煩，於是在一開始設計框架的時候，設計的好一點，這個好估計是當初那麼一代代程式員掉坑爬出來後的精神感悟吧。
然後再關註下代碼本身，將面向對象的特性展現了一大部分。即繼承，封裝，多態。這裡只是一小部分，框架的建設就是圍繞這個特性展開的。不過有一點是這樣的，個人的一點體會：不是為了用到這些特性，將他們放到框架中，
而是為了更好的框架建立，而需要用到這些特性，所以才有了這些特性，才被我們在使用。
有什麼不合適之處請大伙兒指出，共同進步。
