舉一個生活中的小例子，大凡開過學或者畢過業的都會體會到這樣一種郁悶：你要去 n個地方辦理 n 個手續（現在大學合并后就更加麻煩，因為可能那 n 個地方都隔的比較遠）。

但是實際上我們需要的就是一個最后一道手續的證明而已，對于前面的手續是怎么辦的、到什么地方去辦理我們都不感興趣。

實際上在軟件系統開發中也經?；貢龅竭@樣的情況，可能你實現了一些接口（模塊），而這些接口（模塊）都分布在幾個類中（比如 A 和 B、C、D）：A 中實現了一些接口，B 中實現一些接口（或者 A 代表一個獨立模塊，B、C、D 代表另一些獨立模塊）。然后你的客戶程序員（使用你設計的開發人員）只有很少的要知道你的不同接口到底是在那個類中實現的，絕大多數只是想簡單的組合你的 A－D 的類的接口，他并不想知道這些接口在哪里實現的。

這里的客戶程序員就是上面生活中想辦理手續的郁悶的人！在現實生活中我們可能可以很快想到找一個人代理所有的事情就可以解決你的問題（你只要維護和他的簡單的一個接口而已了?。谲浖到y設計開發中我們可以通過一個叫做 Facade 的模式來解決上面的問題。

我們通過外觀模式解決上面的問題，其典型的結構圖為：

外觀模式的想法、思路和實現都非常簡單，但是其思想卻是非常有意義的。并且外觀設計模式在實際的開發設計中也是應用最廣、最多的模式之一。

應用示例：
     假如你想吃一頓大餐，那么我想你要，首先去買菜，然后回到家后自己做菜，最后吃完飯以后要洗碗打掃。
     這么一來你需要3個類，Shopper， Cook， Dishwasher， 分別來完成買菜，做菜，洗碗等工作，顯然這非常麻煩，能不能簡化這個過程？當然可以！去餐館吃。
     餐館這時候顯然就是外觀模式了，他把復雜的過程封裝到內部，用戶不用關心細節。

實現代碼：
Shopper 采購類

class Shopper { public:  void shopForGroceries()  {   cout<<"買菜"<<endl;  }  }; 

Cook 廚師類

class Cook { public:  void doCook()  {   cout<<"做飯"<<endl;  }  }; 

洗碗工類 Dishwasher

class Dishwasher { public:  void washDish()  {   cout<<"洗碗"<<endl;  } }; 

餐館類

class Restaurant { public:  Restaurant()  {   }  void haveAMeal()  {   m_shopper.shopForGroceries();   m_cook.doCook();   m_washer.washDish();  } private:  Shopper m_shopper;  Cook m_cook;  Dishwasher m_washer; }; 

客戶端：

Restaurant rt; rt.haveAMeal();