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)

創建子程序最主要的目的是提高程序的可管理性，當然也有其他一些好的理由。其中，節省代碼空間只是一個次要原因：提高可讀性、可靠性和可修改性等原因都更重要一些。

子程序可以按照其內聚性分為很多類（功能內聚、順序內聚、通訊內聚、臨時內聚過程內聚、邏輯內聚、巧合內聚），而你應該讓大多數子程序具有功能上的內聚性，這是最佳的一種內聚性。

子程序的名字是它的質量的指示器。如果名字槽糕但是恰如其分，那就說明這個子程序設計得很差勁。

轉載于:https://www.cnblogs.com/bsdbch/p/4027935.html

總結

以上是生活随笔為你收集整理的个人阅读 代码大全的阅读与提问的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。