思考c++程式設計－譯自c++ programming language 1.7節 (轉)

思考c++程式設計－譯自c++ programming language 1.7節 (轉)[@more@]思考c++
  理想的狀態下，你完成一個設計任務分為三步。第一，你必須清楚的理解問題(分析analysis)，然後，你要定義在解決方案中關鍵的概念(設計design)，最後，你必須以程式的方式表達出解決方案(程式設計programming)。然而，解決方案中的問題和(關鍵)概念只有透過在程式中努力的表達和執行程式的結果才能夠清晰的表達，這就是選擇程式語言的麻煩之處。
  在大部分程式中，有一些(關鍵)概念不能夠容易的透過基礎型別或不聯絡資料的來表達。給出這樣一個概念，可以在程式中用宣告的一個類來表達它。一個c++類是一種型別(type)，它指出類的例項有怎樣的動作：它們怎樣被建立，它們怎樣被操作，它們怎樣被銷燬。類還可以指出(類的例項)怎樣表現，雖然在程式設計的早期它將不是主要的部分。寫一個好的程式的關鍵是設計一個好的類，它能夠清楚的表達出一個單獨的概念(concept).這意味這你經常的關注於(focus on)下面的問題上:這個類的物件(例項)怎樣被建立？類的物件(例項)能被複製或者銷燬嗎？什麼運算子能夠被應用到這個物件上？如果對於這些問題沒有一個好的回答，那麼也許概念(concept)不是清晰的。用更多的考慮問題和計劃解決方案來代替立即開始編碼也許是一個很好的主意.
  最容易應付的概念是那些已經有了傳統的數學的：數字的排序，集合，幾何圖形等等。面向字元的I/O，字串，基本的容器，在這些容器上的基本的演算法，和一些數學運算類是c++標準類庫的一部分。此外，亂七八糟的各式各樣的支援普遍的和特殊領域的類庫也是可用的。
  一個概念(concept)不可能憑空存在,它總是集合一組有聯絡的概念(concept)，類之間的聯絡由程式組織在一起，就是解決方案中不同概念之間確實存在的聯絡，這經常要比開始是擺放單獨的類要困難的多。最好不要使類的依賴(depend on)關係很複雜。假設兩個類A和B，象"AB的函式","A建立B"和"B是A的成員"這樣的關係是很少導致嚴重的錯誤的。但是象"A使用了B的成員變數"這樣的最好被排除。
  管理複雜的最有力的智慧工具之一是繼承命令，也就是組織一組相聯絡的概念(concept)到一個樹狀結構中，最一般(general)的概念(concept)作為根。在c++中，派生類以這樣的結構表達。一個程式經常被組織為一些樹的集合或者非迴圈的類圖。就是程式設計師指定一些基類，每個類都有派生出的子類。虛擬函式經常被用來定義基類的操作。當必要的時候，這些操作的解釋能被重新定義在子類之中。
  有的時候一個直接的非迴圈類圖不是足夠的組織一個程式裡的概念(concept);有些概念看起來天生的互相依賴.在這種情況下，我們努力的區域性化這些迴圈的依賴，使它們不影響整個的程式結構。如果你不能排除或者區域性化這些固有的依賴關係，你將很可能陷入這些困境，沒有程式語言可以幫助你出來。除非你能想象一些基類(base concept)之間的容易規定的關係(easily stated relationships)。否則程式將變得不可管理。
  解開依賴關係的最好的一個工具就是將介面和實現清楚的分離開。抽象類是c++這麼做的主要工具。
  另一種通用的形式可以用模板來表達，一個類别範本可以指定一族(a family of)類。例如，一個列表(list)的模板指定“類T的列表”，類T可以是任何類。因而，模板是這樣一種裝置，它指定一種型別怎樣被作為引數的另一種型別替代。最一般的模板是一些容器類，象列表(lists),陣列(arrays),聯合陣列(associative arrays)和用在這些容器上的最基本的演算法。如果使用繼承表達將一個類作為類或者函式的引數有錯誤的話，最好使用模板來做。
  記得許多程式能使用原始的型別，資料結構，簡單的函式和很少的類庫，清楚而簡單的完成。可以不定義新的型別，除非它(定義新型別)是真的必要。
  問題"怎樣寫好的c++程式？"和問題"怎樣用英語寫好的散文？"是很相似的。有兩個問題："知道你想說什麼"和"實踐，模仿好的寫法"，這兩個問題是對於寫英語散文的，它們同樣適用於寫c++程式，做起來也是同樣難的。