摘要: 本篇是創建游戲內核（2） 【接口與實現分離版】的續篇，關于該內核的細節說明請參考創建游戲內核（3），這個版本主要是按照功能劃分模塊的思想，并嚴格按照接口與實現相分離的原則來寫的，沒有用面向對象的思想來寫，沒有繼承沒有多態。大家可以對比兩個版本，比較優劣。
閱讀全文
摘要: 本篇是創建游戲內核（1） 【接口與實現分離版】的續篇，關于該內核的細節說明請參考創建游戲內核（2），這個版本主要是按照功能劃分模塊的思想，并嚴格按照接口與實現相分離的原則來寫的，沒有用面向對象的思想來寫，沒有繼承沒有多態。大家可以對比兩個版本，比較優劣。
閱讀全文
摘要: 程序員都是聰明人，沒有誰愿意干重復勞動這樣的傻事，因此，程序中出現重復代碼是程序員的恥辱。就算不能消除重復代碼，至少也可以對于相同的功能，用不同的代碼來實現所以發明新輪子的程序員才會那么多。
面向對象作為一種橫空出世的新技術，首先承諾的就是“更好的重用性”，而“重用性”這樣一個閃閃發光的詞，也的確能夠吸引程序員的實現，那么多新的理論、新的技術、新的方法、新的框架、新的思想，用來說服別人接受的一個最大的理由，就是“更好的重用性”。然而，OO以及一直以來不斷發展的 OO相關技術，對于重用性的提高，作出了多大的貢獻呢？
閱讀全文
摘要: 面向過程的世界是完整的，統一的，也是容易理解的——對于程序員來說——或者說他只需要一種理解能力。這個世界雖然值得懷念，卻不值得再回去。因為，我們不再像當年的程序員那樣，只開發那些簡單的軟件了。很多人崇拜那些早起的“大牛”，其實平心而論，我們現在面對的問題的復雜程度，在他們當年可以說幾乎無法解決。需求的復雜程度也不是他們當年能夠設想到的。
閱讀全文
摘要: 關于該內核的細節說明請參考創建游戲內核（1），這個版本主要是按功能劃分模塊的思想，并嚴格按照接口與實現相分離的原則來寫的，沒有用面向對象的思想來寫，沒有繼承沒有多態。大家可以對比兩個版本，比較優劣。
閱讀全文
摘要: 良好的設計應該只暴露接口給用戶，所有的實現細節對用戶來說應該是隱藏的，也就是說用戶只要給接口傳遞相應的參數就行了，不需要管內部是如何實現的，比如我們使用fopen，fseek，CreateWindow等函數會發現很好用，而不需要管fopen，fseek，CreateWindow函數內部代碼是如何實現的，數據結構是如何組織的，也就是說絕對不能暴露任何的細節給用戶，包括數據組織在內。
閱讀全文
摘要: 前面介紹了如何初始化聲音系統以及如何加載聲音數據，很自然地，接下來就要講述如何播放聲音了，這也正是SOUND_CHANNEL類的用途所在。
閱讀全文
摘要: SOUND對象控制DirectSound和DirectMusic對象，控制回放聲音時的音量（全局音量控制），也觸發音頻流相關消息。
閱讀全文
摘要: 繼承關系是一種耦合度很高的關系，它與組合及一般化（genericity）一樣，提供了OO中的一種基本方法，用以將不同的軟件組件組合起來。一個類的實例同時也是那個類的所有的祖先的實例。為了保證面向對象設計的有效性，我們應該保存下這種關系的一致性。在子類中的每一次重新定義都應該與在其祖先類中的最初定義進行一致性檢查。子類中應該保存下其祖先類的需求。如果存在著不能被保存的需求，就說明了系統的設計有錯誤，或者是在系統中此處使用繼承是不恰當的。由于繼承是面向對象設計的基礎，所以才會要求有一致性檢測。C++中對于非虛擬函數重載的實現, 意味著編譯器將不會為其進行一致性檢測。C++并沒有提供面向對象設計的這方面的保證。
閱讀全文
摘要: C++允許在參數類型不同的前提下重載函數。重載的函數與具有多態性的函數（即虛函數）不同處在于：調用正確的被重載函數實體是在編譯期間就被決定了的；而對于具有多態性的函數來說，是通過運行期間的動態綁定來調用我們想調用的那個函數實體。多態性是通過重定義（或重寫）這種方式達成的。請不要被重載 (overloading)和重寫(overriding)所迷惑。重載是發生在兩個或者是更多的函數具有相同的名字的情況下。區分它們的辦法是通過檢測它們的參數個數或者類型來實現的。重載與CLOS中的多重分發（multiple dispatching）不同，對于參數的多重分發是在運行期間多態完成的。
閱讀全文