剛起步機房時，不知道怎麼加入的抽象工廠，反射，配置檔案等這些東西，當時隻是在七層的了解上稍微有些思路，這是當時的部落格《七層連連串》，回頭看自己的部落格時 ，感覺當時了解的還是比較深刻的，可是我想問自己，當初是怎麼想到抽象工廠的？隻是在“模仿”巨人嗎？
當個人重構雛形已出，現在有必要重新認識一下抽象工廠，反射，配置檔案。
抽象工廠模式的出現就是與具體資料庫通路解除了依賴，就是說對具體的資料庫（sql，access等）進行了抽象，俗稱抽象工廠。
反射：提供了封裝程式集，子產品和類型的對象。反射的用法在《七層連連串》有設計。
配置檔案：以UI層的配置檔案為主。名稱為App.config, 好處就是，在程式打包後，配置檔案會自動生成一個檔案，而使用者可打開該檔案進行更改，換句話說，就是避免了更改源碼。
抽象工廠背景：
想要知道為什麼引入抽象工廠，就得從接口入手。
為什麼要使用接口呢，現在的軟體産品不可能指針對一個資料庫，那麼如何讓一套程式既可使用SQL Server又可使用Access作為資料庫呢，答案是我們在資料通路層使用統一的接口，讓通路SQL Server和Access的類都實作這個接口，然後通過接口調用具體的實作。
接口就可以實作通路不同的資料庫我們為什麼采用工廠模式呢，原因有兩個，第一是客戶提出新需求，自己不改變源碼就更換為其他資料庫；第二是從開發公司考慮，為了适應不同的資料庫，每次需要修改BLL層源代碼，再編譯程式，釋出程式比較麻煩。那麼具體實作步驟是建立新的工廠項目類，然後在類中實作傳回實作産品接口的方法，通過Config讀取配置資料，針對不同資料庫，傳回不同實作接口的對象，最後修改BLL層的調用方式為簡單工廠調用，用接口隐示聲明，但是實作通過工廠建立，這樣我們就可以通過修改配置檔案實作不同資料庫的通路，實作了簡單工廠的設計模式。
有了簡單工廠，為什麼還要使用抽象工廠呢，原因是一個大的軟體項目中包括很多的子產品，不同的子產品就要建立不同的接口，那麼如何傳回很多實作接口的對象呢 ，在簡單工廠模式中隻能編寫多塊相似的代碼，通過判斷資料庫的類型傳回具體的對象，這樣就造成大量的代碼備援，這裡采用優化的方法，即抽象公共的部分，通過抽象類調用具體的實作類，可以産生一批有關聯的産品，例如通過配置檔案讀取是Access資料庫類型，那麼得到是Access的工廠，工廠裡的産品都是通過通路Access資料庫資料産生的産品。可以說對于簡單工廠模式一次隻能建立一個對象，而對于抽象工廠模式實作一次建立一系列互相依賴對象的需求。
抽象工廠類圖：
抽象工廠的出現，解決了更換資料庫的麻煩，可是另一個問題伴随而出，如果更改資料庫，豈不是還是要動代碼？按照小菜的話說，這樣豈不是要寫死在代碼裡？是以，為了解決這一問題 ，又引入了”配置檔案“，詳解請見下篇部落格《個人重構——配置檔案》。