1.如何封裝？
封裝總被提及，但是封裝除了隱藏細節，還有什麼需求呢？封裝不僅僅是有簡化過的模型看到複雜的概念，而且同時還不能讓你看到複雜概念的任何細節。隱藏資訊的重要性毋庸質疑。所以我們現在不僅用 C++ 的 private 隱藏資訊。還用介面的方法，不在標頭檔案暴露任何設計細節。另外，任何一個不滿足現狀的程式設計師，對自己以前的程式碼一定不會滿意。但是複用老的不滿意的程式碼並非壞事。我們需要做的是，重用的時候，把老的東西隱藏起來。
2.防禦性程式設計是什麼?
防禦式程式設計的主要思想是：子程式應該不因傳入錯誤資料而被破壞，哪怕是有其他子程式產生的錯誤資料。簡單點講就是容錯性。
要點：
最終產品程式碼中對錯誤的處理方式要對“垃圾進，垃圾出”複雜得多。
防禦式程式設計技術可以讓出錯誤更容易發現、更容易修改，並減少錯誤對產品程式碼的破壞。
斷言可以幫助人儘早發現錯誤，尤其是在大型系統和高可靠性的系統中，以及快速變化的程式碼中。包含C++
、Java和Microsoft Visual Basic在內的很多語言都支援斷言，比如C++中標準的aasert巨集並不支援文字訊息。
3.耦合的種類有哪些？
鬆散耦合是每個系統設計人員所追求的東西。但是其標準往往把握不準。舉個簡單的例子，不一定恰當。在我最早的設計裡，系統把座標這個東西封裝成一個叫做 point ，以後引數傳遞都傳 point * ，而不是 x,y 。這看使很合理。但是，這的確增加了耦合度。因為每個類都需要知道 point 的細節。很多情況下，用簡單型別做引數傳遞反而更合適。(到底傳 point * 還是 x,y 依舊要根據實際情況靠量) 引數過多也會導致耦合度的增加，從這個角度看，x,y 是兩個引數， point * 是一個引數。關於耦合程度的問題，沒有絕對唯一的標準。
4.需求分析如何做？
其實我們不必去照本宣科的寫需求分析書什麼的，做需求分析即使是在大腦中，口頭交流上完成，也是有這麼一個過程。落下文字固然是好的，但並不是重點。關鍵在於做不做。是否詳細定義了系統的全部輸入，包括來源、精度、取值範圍、出現頻率。是否詳細定義了系統全部輸出，包括目的，精度，取值範圍、出現頻率，格式？是否定義了機器記憶體和剩餘磁碟空間的最小值？是否詳細定義了系統的可維護性，包括適應特定功能的變更、操作環境的變更、與其他軟體的介面的變更能力？ 書中列的遠比我這裡列出的多，非常值得一讀。定下這些是很重要的，我覺得合理的遊戲開發，是有一個相對穩定的策劃方案，和一些已經完成完成的美術資源。大部分的變更都留在下一版本去做。策劃和美術永遠為下一個版本工作，而程式可以根據相對穩定的需求做設計。這樣做，即使第一個版本是不可玩的，扔掉，也是能讓遊戲最終成功。
5.怎麼寫一個高質量子程式？
子程式程式碼長度最好控制在200行之內，如果超過200行，會在可讀性方面遇到問題。
把巨集表示式整個包含在括號內，比如：#define Cube(a) (a*a*a)
建立子程式最主要的目的是提高程式的可管理性，當然也有其他一些好的理由。其中，節省程式碼空間只是一個次要原因：提高可讀性、可靠性和可修改性等原因都更重要一些。
子程式可以按照其內聚性分為很多類（功能內聚、順序內聚、通訊內聚、臨時內聚過程內聚、邏輯內聚、巧合內聚），而你應該讓大多數子程式具有功能上的內聚性，這是最佳的一種內聚性。
子程式的名字是它的質量的指示器。如果名字槽糕但是恰如其分，那就說明這個子程式設計得很差勁。