在上一周的讀書筆記中，我介紹了狀態模式的概念與運用，在這一周的筆記中我要介紹另外一種模式——外觀模式（facede）。
上一周講解了狀態模式，主要是遊戲又很多不同的狀態，這些狀態（子系統）的相互轉換，如果採用常規的一些分支語句方法，會使得效率變得十分低下，因此狀態模式可以理解成是控制這些狀態轉換的開關。但是在遊戲裡面這些子系統（例如遊戲事件系統、關卡系統、角色管理系統）內部是怎麼樣實現的呢？而且在遊戲執行時候這些子系統之間必定會進行互相呼叫和輸入玩家的引數以及執行結果。如果我們直接呼叫這些子系統的話，可能就會變得非常麻煩，我在此不進行贅述，直接貼乙個常規**。
public class battlestate
public void update()
//設定狀態為戰鬥狀態
}
有兩個非常嚴重的缺點：
1.違背了物件導向的七大原則之一的：單一職責原則，我們狀態類僅僅是需要負責遊戲在「戰鬥模式」下的功能執行以及進行狀態切換，而不會負責遊戲子系統的初始化，執行操作以及相關的整合工作。
2.從「可重用性」來看，這種設計方式不容易轉換給其他的專案使用，因為戰鬥類繫結了其他太多的子系統，一動全部都要改。
從這兩點來看，這種一般的設計方式使得**耦合性太大，不便於修改和使用。那麼這個時候就要請出我們的外觀模式
依然引用原書中的定義：「為子系統定義一組統一的介面，這個高階的介面會讓子系統更容易被使用」。
可能這樣看起來十分抽象，但本書又正好提供了乙個非常貼切形象的比喻。
以駕駛汽車為例，汽車想要跑起來肯定需要人駕駛，但是人駕駛只是乙個外部的操作過程，而內部的實現依然需要引擎系統、傳動系統、懸吊系統、車身骨架系統、電裝系統。但那麼多老司機，他們難道都是機電工程師？他們都會使用這些內部設施嗎？答案顯然是否定的，他們是通過駕駛台上面的各種功能按鈕。比如我要啟動就可以按這個，要剎車就可以踩腳踏板。而這裡的駕駛台，就可以理解成乙個高階的介面，而司機就是客戶端。
外觀模式可以用下面的這個圖來形容。
原本需要參與的角色都被高階介面所包裝了，我們只需呼叫這個高階操作面板，進行操作就行。
那麼在遊戲中只需要使用外觀模式實現遊戲主程式，模擬**如下：
namespace 外觀模式
}class b
}class c
}class d
}/// /// 高階面板類
///
class mainstategame
public void gameover()
public void backpage()
public void fightsystem()
public void sellmall()
}/// /// 狀態類
///
class program}}
轉職遊戲策劃第三週
工作 第三週我根據文件格式在弄給美工的人物模型設定，之前是根據鹿鼎記 找需要的人物，還學了ps資源摳圖 第三週專案進度，策劃這邊，在弄粒子系統，從現有網上遊戲資源裡扒素材，尋找合適我們遊戲的粒子效果 主程式在弄 任務和戰鬥系統 這一周 遊戲策劃甚至遊戲行業對於我的上限還很高，還可以學到的東西有好多，...
第三週作業（二）讀程式
問題1 這個程式要找的是符合什麼條件的數？問題2 這樣的數存在麼？符合這一條件的最小的數是什麼？問題3 在電腦上執行這一程式，你估計多長時間才能輸出第乙個結果？時間精確到分鐘 電腦 單核cpu 4.0g hz，記憶體和硬碟等資源充足 問題4 在多核電腦上如何提高這一程式的執行效率?using sys...
設計模式與遊戲完美開發 抽象工廠
它就是工廠模式的公升級版，可見上圖 它與工廠模式的區別就是抽象化了，而工廠模式的工廠是具體的，例如 將上面的深圳工廠拆出來，我不需要其他城市的工廠了 例如都倒閉啦 哈哈 就變成工廠模式了。而且這種工廠模式正是我介紹的工廠模式第二種形式的實現方法的小改動一下，原本是乙個介面 建立產品 外部還需要摻入乙...