模擬餐廳經營。
需求：
我們現在要開一個餐廳啦，餐廳裡面有服務員，有廚師，有顧客。學習物件導向，為餐廳和幾個角色建立自己的類吧。
餐廳可以招聘或者解僱職員，職員越多，就越能夠滿足更多的顧客需求，從而賺取更多的錢
餐廳裡的容量是有限的，當顧客坐滿了，其他顧客需要排隊
服務員的工作有兩個職責，一個是負責點菜，另外一個是上菜
廚師的職責就一個，烹飪食物
顧客可以做兩件事情，一個是點菜，一個是吃
這一系列寫了很久。主要使用到的設計模式是職責鏈模式和觀察者模式。
工廠模式、命令模式、介面卡模式、橋接模式這樣的都會穿插在其中，可能是平時用習慣了，所以沒有刻意是哪種設計模式。
要有覆盤的好習慣，這個模擬還會有些視覺化的地方需要改進和新增，所以還在繼續更新。
職責鏈模式
這個模式給我最大的體會是，它更像一箇中轉站，用於資料處理的。用switch與type來判斷是哪一種的資訊，作出哪一種處理。
職責鏈模式可以比喻成有序火車，而火車站裡面有個函式充當時序表，但是不知道火車什麼時候到，卻知道該去哪。不好的是容易繞，得不斷順著走，繞出個邏輯來才行。
開始 >> 中轉站 >> 方法A >> 中轉站 >> 中轉站 >> ...... >> 方法B >> 中轉站 >> 方法C >> 結束
switch (type) {
case 'A': {
// do Something
break;
}
case 'B': {
// do Something
break;
}
case 'C': {
// do Something
break;
}
case 'D': {
// do Something
break;
}
}觀察者模式
觀察者模式實現不難，但是邏輯很精密，拍手驚歎。
以模擬餐廳作為例子。顧客、服務員、廚師相互之間進行解耦。
顧客有很多，服務員和廚師也可以有很多。就會有一個類似於"管理者"的角色，可以是Object或者Array。初始化的時候就發起監聽。當需要服務員或者廚師的時候，就釋出來響應監聽。而這個"管理者"的角色起到的作用就是找到空閒人員再分配任務。因為當釋出訊息的時候，是會讓所有監聽者都會接收到訊息。如果不以"管理者"的形式監聽，而以職員單體的形式監聽。例如當一個顧客需要服務員的時候，所有服務員都會響應，這就有點糟糕了。
let Observer = (function () {
var _messages = {};
return {
// 註冊資訊介面
regist : function (type, fn) {
// do Something
},
// 釋出資訊介面
fire : function (type, args) {
// do Something
},
// 移除資訊介面
remove : function (type, fn) {
// do Something
},
}
})();小小的總結和覆盤。持續修改