無廢話c#設計模式之八：facade
意圖
為子系統中的一組介面提供乙個一致的介面，facade模式定義了乙個高層介面，這個介面使得這一子系統更加容易使用。
場景
在乙個為遊戲充值的**中，建立訂單需要與三個外部介面打交道：
l使用者系統：根據使用者名稱獲取使用者id、檢視使用者是否已經啟用了遊戲
l卡系統：檢視某種型別的充值卡是否還有庫存
l充值系統：建立乙個訂單，並且返回訂單號
如果直接讓**和三個外部介面發生耦合，那麼**因為外部系統介面修改而修改的概率就很大了，並且就這些小介面來說並不是十分友善，它們提供的大多數是工具方法，具體怎麼去使用還是要看充值**建立訂單的邏輯。
facade
的思想就是在小介面上封裝乙個高層介面，遮蔽子介面的呼叫，提供外部更簡潔，更易用的介面。
示例**
usingsystem;
usingsystem.collections.generic;
usingsystem.text;
namespacefacadeexample
}
classpayfacacde
}
classaccountsystem
publicintgetuseridbyusername(stringusername)
}
classcardsystem
}
classpaysystem
}
}
**執行結果如下圖：
**說明
lpayfacade
類就是門面型別，提供給客戶端呼叫，它本身呼叫子介面。可以看到，建立乙個訂單首先要根據使用者名稱獲取使用者id、然後要看使用者是否已經啟用了遊戲、然後看充值卡是否有庫存，最後才是建立訂單。
laccountsystem
、cardsystem以及paysystem就是子介面，它們提供了賬戶、卡以及充值相關的一些介面方法。
lfacade
模式太常用了，把和多方關聯的邏輯**再進行一次封裝，提供乙個高層介面就是facade的思想。比如在做論壇程式的時候，一些操作需要呼叫許可權訪問模組（發帖、管理帖子），另外一些操作可以直接呼叫（首頁論壇板塊、登陸）資料訪問模組，由**來做這個判斷並呼叫不同的子模組並不合適，可以加乙個業務邏輯層來統一接受**各種操作請求，這其實就是facade。
何時採用
l從**角度來說， 如果你的程式有多個類是和一組其它介面發生關聯的話可以考慮在其中加乙個門面型別。
l從應用角度來說， 如果子系統的介面是非常細的，呼叫方也有大量的邏輯來和這些介面發生關係，那麼就可以考慮使用facade把客戶端與子系統的直接耦合關係進行化解。你可能會說，子系統改了門面不是照樣改？的確是需要改，但是如果客戶端本身的工作已經比較複雜，或者說可能有多個需要呼叫門面的地方，這個時候門面的好處就體現了。
實現要點
l通過乙個高層介面讓子系統和客戶端不發生直接關聯，使客戶端不受子系統變化的影響。
lfacade
不僅僅針對**級別，在構架上，特別是web應用程式的構架上，facade的應用非常普遍。
注意事項
lfacade
不一定只能是乙個，可以考慮把門面進行細分。
（原創）無廢話C 設計模式之八 Facade
無廢話c 設計模式之八 facade 意圖 為子系統中的一組介面提供乙個一致的介面，facade模式定義了乙個高層介面，這個介面使得這一子系統更加容易使用。場景 在乙個為遊戲充值的 中，建立訂單需要與三個外部介面打交道 l使用者系統 根據使用者名稱獲取使用者id 檢視使用者是否已經啟用了遊戲 l卡系...
（原創）無廢話C 設計模式之五 Prototype
無廢話c 設計模式之五 prototype 意圖 用原型例項指定建立物件的種類，並且通過拷貝這些原型建立新的物件。場景 遊戲場景中的有很多相似的敵人，它們的技能都一樣，但是隨著敵人出現的位置不同，這些人的能力不太一樣。假設，我們現在需要把三個步兵組成一隊，其中還有乙個精英步兵，能力特別高。那麼，你或...
（原創）無廢話C 設計模式之九 Proxy
無廢話c 設計模式之九 proxy 意圖 為其他物件提供一種 以控制對這個物件的訪問。場景 模式非常常用，大致的思想就是通過為物件加乙個 來降低物件的使用複雜度 或是提公升物件使用的友好度 或是提高物件使用的效率。在現實生活中也有很多 的角色，比如明星的經紀人，他就是一種 經紀人為明星處理很多對外的...