面向對象的C++設計雜記

任何對本文的引用，請指明出處。

本文是面向對象的C++設計方面的一個雜記。我會一天寫一點直至完成。

1.類設計的CheckList

koenig有篇關于類設計的checklist的文章非常好，我摘抄這個list如下：

1. 私有資料。如果不想将特有的資料暴露給外部，請使用函數來讓外界通路私有資料；
2. 構造函數。如果類對象需要特殊的處理來完成對象内部功能的建造，就需要考慮構造函數；
3. 預設構造函數。如果該類對象不需要顯示初始化，就需要預設構造函數；
4. 所有構造函數需要初始化所有資料成員嗎？
5. 需要複制構造函數嗎？如果構造函數内配置設定了資源，請考慮複制構造函數
6. 析構函數。如果類配置設定了資源，請在析構函數内釋放
7. 類需要虛拟析構函數嗎？如果需要繼承的子類對象有多态的對象删除就需要虛拟析構函數
8. 需要指派運算符嗎？如果存在複制構造函數，多半需要指派運算符
9. 指派運算符考慮自身指派了嗎？
10. 需要定義關系運算符嗎？如果想建立類的有序集合，則需要定義關系運算符
11. 删除數組時調用delete[]了嗎？
12. 複制和指派構造函數參數加const了嗎？
13. 如果函數有引用參數，它們應該是const引用嗎？
14. 成員函數是const嗎？

2.面向對象的軟體設計感想

軟體設計需要豐富的經驗和對問題域深入的了解，這是一個重要的先決條件。我見過許多所謂的軟體設計人員，甚至号稱為架構師的進階設計人員，對問題域都沒有做深入的了解就進行所謂的軟體設計，甚至指導真正的開發人員進行開發。荒謬到了極點，最終的軟體讓人啼笑皆非。其中充斥着不合時宜的所謂的子產品，無法适應新的需求，開發人員天天就忙于fix bugs。我很是納悶，如此差勁的所謂的設計人員安排都拿着高昂的薪水，冠着“設計師”的光環，竟然在許多組織中大行其道，而沒有在管理上采取必要的措施......，可悲！！！

我從事軟體開發好多年了，見過許多優美的設計，也見過許多象垃圾一樣的東西。對于一個事物是否優美，不同的人審美觀念不同，答案也不同。有的人喜歡華麗輝煌，有的人喜歡簡潔樸素。我本人喜歡後者，一個複雜的問題，被簡單幹淨痛快地解決掉，還有比這更漂亮的設計嗎？是以這其中有一個設計哲學和理念的問題。我推崇“簡潔”，軟體領域我相信超過80%的人和我一樣。但是“簡潔”不意味着“簡單”、“粗糙”、“原始”，我總結了幾點優美的設計必備的要素：

1）概念清晰簡潔。所有子產品及功能是單純和清晰的，角色是明确的

2）對象關系層次清晰明了。

3）多一分則多，少一分則少。恰到好處的拿捏是很技術的

4）靈活。能靈活地适應變化

5）關鍵的一點設計不能偏離一個中心：需求。設計得再優美，如果偏離了需求，就象緣木求魚又有什麼意義呢？

我看到過許多所謂的架構師對第5）點缺乏根本的把握，“唯美”的設計如果脫離了現實的環境和實際的運用，又有什麼存在的必要呐？

3.設計模式學習的幾個階段

設計模式已經流行多年了，模式概念的興起是軟體行業設計和開發的一大進步。模式将常見的問題的解決方法程式化，同時在廣大開發人員中形成一種共同的語言。現在簡直成了檢查一個軟體工程師水準的一種方法和手段。觀察周邊的同道對模式的認識上大緻有如下的幾個階段：

1. 初級階段。隻知道幾個模式的名字，生搬硬套地使用。一碰到問題不能一下就正确地標明合适的模式，正确地處理細節。
2. 中級階段。熟悉各個模式的應用範圍和背景，能區分應用的場合，正确地使用。能夠适當的對模式進行裁剪和擴充
3. 進階階段。無招勝有招的出神入化階段。同時積累了大量的自有模式，對特定行業常用模式有豐富的經驗和把握。