C++及其標準庫概覽---第二,三章

 題外話:自從寫完第一篇總結之後,自己就擱置很久沒寫這個學習筆記了。並不是說自己很懶或者沒毅力,而是越到後面越覺得,C++真的是不簡單啊!自己想在認真看完一遍,做到心中有一些概念之後再回頭來好好研究細節,這樣才能使自己的總結真正有內容,或者說有意義。

      在第一章中,作者主要是籠統的告訴我們C++是什麼,該怎麼學,至於具體到怎麼用,用到哪些方面更適合更強大則是放在了這兩章講述。設計C++就是爲了支持數據抽象,面向對象的程序設計和通用型程序設計,以及在這些風格約束之下的傳統的C程序設計技術。它從未有意要給其用戶強加某種特殊的程序設計風格。

      開始的過程式程序設計,其設計範型是:確定你需要那些過程,採用你能找到的最好的算法。從程序組織的觀點看,函數被人們用於在許多算法的迷宮裏建立起一種秩序。而隨着程序規模的迅速增大,設計程序的着重點則慢慢的從有關過程的設計轉移到對數據的組織上。以及相關的過程與被它們所操作的數據組織在一起,通常稱作一個模塊。而這種模塊程序設計的範型是:確定你需要哪些模塊,將程序分爲一些模塊,使數據隱藏於模塊之中。(這一範型也被作爲數據隱藏原理而廣爲人知!)可以說,模塊化是一切成功的大型程序的一個最基本特徵。

      然而,很多時候,模塊化的形式對於清晰地表達複雜的系統而言還是不夠的。在定義用戶自主創建的類型時尤爲如此。綜合一下,主要存在以下兩個問題:1.這種定義類型的模塊給用戶提供了一個“假類型”的表示,它可以因爲表示類型不同而出現很大的變化----而與從同時,又應該將用戶隔離於這一表示之外。2.更根本的問題是,通過模塊實現的這種用戶定義類型,它們所提供的對類型的訪問,在行爲上,並不像內部的類型。它們得到的支持也與內部類型不一樣,而且實際上更少一些。

      C++解決這個問題的方式就是允許用戶直接定義類型,這種類型的行爲方式(幾乎)與內部類型完全一樣。這樣的類型常常被稱作抽象數據類型,更普遍的術語便是用戶定義類型。而這時程序設計規範變成了:確定你需要哪些類型,爲每個類型提供完整的一組操作。

      但是,必須提醒的一點就是,這種具體類型的出現(更一般的說法是,類概念的出現與支持),並不等於OOP的發展,相反,它還存在自身的很大不足,那就是:一旦這種“黑匣子”定義好之後,它也就無法再與程序的其他部分進行實際地交互了,也就是說,沒有任何方式可以爲了某些新用途而調整它,除非去修改它的定義。這個問題的關鍵就是類的層次結構造成程序的冗餘與難以維護,當一個新情況出現並且必須加以考慮時,只能硬性的去該原類型定義,而這卻可能帶來很多潛在的致命的問題。而要解決這個問題,就必須很好的定義這種類結構。也就是區分出類的共有特徵與特殊特徵,從而能在高層類結構不變的情況下,花費最小的代價處理新情況。而表達這種區分並由此獲益就定義了面向對象的程序設計。

      事實上,在類型之間,能夠通過使用繼承和虛函數挖掘出的共性的數量,可以看做是面向對象程序設計對於某個問題的適用性的一個石蕊檢驗。而現在的程序設計範型是:確定你需要哪些類,爲每個類提供完整的一組操作,利用繼承去明確地表達共性。

      當然,說了這麼多,最可能的情況是,讓人覺得新的設計範型總是比舊的好,其實這是不正確的。很多時候,一種新的範型的出現勢必是因爲程序設計現狀的要求,對於用戶的服務需要更高的更新的滿足。但這並不說明對於那些舊的程序和一些特殊的新問題就都應該使用新的設計範型重新書寫。(事實上,每一種安全性與便捷性的提高貌似都付出了一定的代價!)例如,在那些不存在於數據相關的過程組之處,採用過程式設計也就足夠了。而另一方面,這些新舊設計範型並不是對立的,他們有一個共同目的,那就是爲程序員提供更好的設計實現之路。繼續上面的話題就是,設計“好過程”的技術其實也可以應用到模塊中的各個過程。

      根據Bjarne Stroustrup的觀點,在那些對於每個類型都只需要一個對象的地方,採用模塊方式實現數據隱藏風格的程序設計也就足夠了。而在不存在共性的地方,簡單的數據抽象就足夠了,並需要去牽扯麪向對象的東西。總之,列在這裏的所有範型都是相互補充的,常常是相互支持的。類和函數都包含着函數,而模塊又包含着類和函數。有經驗的程序員會根據需要去選擇使用各種不同的範型。

      最後要說的就是通用型程序設計了。它的設計範型是:確定你需要哪些算法,將它們參數化,是他們能夠對各種各樣適當的類型和數據結構工作。可以說,這是一種更高層次的數據抽象。(PS:模板是一種編譯時的機制,因此,與“手工編寫的代碼”相比,他們的使用並不引起任何額外的運行時開銷。)而STL中的容器與相關算法也正是根據這種思想設計而來的。

      語言特徵的存在是爲了支持各種各樣的程序設計風格核技術,因此,學習一門語言的工作應該是集中於去把握對該語言而言固有的和自然的風格---而不是去理解該語言的所有語言特徵的細枝末節。在實踐性的程序設計中,理解語言中最晦澀難懂的的語言特徵,或者使用最大量的不同特徵並不能獲得什麼利益。把一種特徵孤立起來看並沒有什麼意思,只是在有技術和其他特徵所形成的環境裏,這一特徵才獲得了意義和解釋。


 

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章