程式碼大全 閱讀與提問

不慎獨不成活發表於2014-10-16

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)

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

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

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

相關文章