標籤：設計模式
今天與阿真同學簡略討論了一下面板模式和抽象工廠+反射+設定檔在機房重構中的應用，引發了幾個簡單的思考，現與君共勉：
1. B層為什麼覺得按照資料庫表來劃分比較合理？ 思考再三：B層方法是實現對資料表的增刪改查進行邏輯操作，而且還要考慮解耦效果（我是這麼理解耦合的，如果一個類中只放一個方法，一旦出錯，它隻影響自己，耦合度就低；如果有十個方法，一個方法出錯，該類的執行個體化就會出錯，這樣耦合程度就越強），所以B層的類中放的方法不應太多；考慮到每個表單大部分都是對一張表進行的操作，這樣，將每張表對應的增刪改查操作放到一個B層類中，大部分調用時只需要執行個體化一個B層類就可以實現對整個表單的操縱任務，既減少程式執行流程，又減輕電腦負擔，何樂而不為呢？
2. 外觀層可不可以用一個類來實現呢？對比於一個表單一個facade類有什麼區別？外觀類按照資料表來分有什麼壞處？
討論想法：外觀類先對方法執行個體化然後再調用的，每執行個體化一次，相當於把外觀中用到的類都執行個體化了一次，無論是用到還是沒有用到的。 如果facade用一個類實現所有B層方法，那麼20多個表單每個表單調用都要執行個體化一次facade類，就是B層所有的方法都調用了20多次，造成大量無用程式的執行。
一個表單一個facade類，用到facade類中執行個體化的方法都是馬上要用到的，這樣所有B層方法執行個體化次數大大降低，基本上就是每個執行1--2次，這樣電腦的負擔不會很大了。
還是同樣的分析方法，儘管B層方法不會調用多次，但諸如上機結賬等表單不止用到一張表，而恰恰Facade類也是按照表分的，那麼對Facade類的調用次數勢必會增加。
3. 抽象工廠+反射+設定檔的應用優勢
說到工廠家族，難免會想到它們對switch語句的鐘愛，但如果資料庫表的數目過於龐大，又要求可以使用不同的資料庫切換時，swtich難免會增加許多無謂的判斷，這樣通過工廠+反射+設定檔的方式，實現對D層方法直接調用，同時容易實現對資料庫的切換。
【總結】
在機房設計初期只是聽說這些設計方法和設計模式就直接加以應用了，而且對面板模式應用認識不到位，導致U層出現了很多邏輯判斷，反過頭來思考才能意識到這些設計模式的妙處，相信對接下來的設計模式的應用學習會更加靈活方便。
機房收費系統--設計模式思考
