c++ 面向?qū)ο蟮念愒O計
類的設計在于用恰到好處的信息來完整表達一個職責清晰的概念,恰到好處的意思是不多也不少,少了,就概念就不完整;多了,就顯得冗余,累贅,當然特例下,允許少許的重復,但是,這里必須要有很好的理由。冗余往往就意味著包含了過多的信息,概念的表達不夠精準,好比goto,指針,多繼承這些貨色,就是因為其過多的內(nèi)涵,才要嚴格限制其使用。好像,more effective c++上說的,class的成員函數(shù),應該是在完整的情況下保持最小化。但是,這里我們的出發(fā)點,是成員數(shù)據(jù)的完整最小化。
最小化的好處是可以保持概念最大的獨立性,也意味著,可以用最小的代價來實現(xiàn)這個概念,也意味著對應用層的代碼要求越少,非侵入式?好比c++11 noexcept取代throw(),好比從多繼承中分化出來接口的概念,好比不考慮多繼承虛繼承的普通成員函數(shù)指針。又比如,如果不要求只讀字符串以0結(jié)束,那么就可以把只讀字符串的任何一部分都當成是只讀字符串。類的對外功能固然重要,但是,類不能做的事情,也很重要。
首先是要有清晰的概念以及這個概念要支持的最基本運算,然后在此基礎上組織數(shù)據(jù),務求成員數(shù)據(jù)的最小化。當然,概念的產(chǎn)生,并非拍著腦袋想出來的,是因為代碼里面出現(xiàn)太多那種相關數(shù)據(jù)的次數(shù),所以就有必要把這些數(shù)據(jù)打包起來,抽象成一個概念。好比說,看到stl算法函數(shù)參數(shù)到處開始結(jié)束的迭代器,就有必要把開始結(jié)束放在一起。比如說,string_view的出現(xiàn),這里假設其字符存儲類型為char,string_view就是連續(xù)char內(nèi)存塊的意思,可以這樣表示
struct string_view { const char* textBegin; size_t length; //或者 const char* textEnd };
這里的重點是,string_view里面的兩個成員字段缺一不可,但是也不必再添加別的什么其他東西。然后,在這兩個數(shù)據(jù)上展開實現(xiàn)一系列的成員函數(shù),這里,成員函數(shù)和成員字段這兩者,有一點點雞生蛋生雞的糾結(jié),因為必要成員函數(shù)的集合(原始概念的細化),成員函數(shù)決定了成員字段的表示,而成員字段定下來之后,這反過來又能夠驗證成員函數(shù)的必要性。不管怎么說都好,成員函數(shù)的設計,也必須遵從最小完整化的原則。再具體一點,就是說但凡一個成員函數(shù)可以通過其他成員函數(shù)來實現(xiàn),就意味著這個函數(shù)應該趕出類外,作為全局函數(shù)存在。當然,這也不是死板的教條,有些很特殊的函數(shù),也可以是成員函數(shù),因為成員函數(shù)的使用,確實很方便。
可能會有疑惑,感覺所有的成員函數(shù)其實都可以是全局函數(shù)?;蛘哒f,我們可以對每一個成員字段都搞一對set、get的函數(shù),那么所有的其他成員函數(shù)就可以是全局函數(shù)的形式,很容易就可以遵守最小完整化的原則。當然,這是明顯偷懶,拒絕思考的惡劣行為。與其這樣,還不如就開放所有的成員字段,那樣子就落入c語言的套路了。所以的法論是,一個函數(shù),這里假設是全局函數(shù),如果它的實現(xiàn)必須要訪問到成員字段,不能通過調(diào)用該類的成員函數(shù)(一般不是get,set)來達到目的,或者,也可以強行用其他函數(shù)來完成任務,但是很麻煩,或者要付出時間空間上的代價,那么就意味著這個函數(shù)應該是該類的成員函數(shù)。
類的設計,就是必不可少的成員字段和必不可少的成員函數(shù),它們一起,實現(xiàn)了對類的原始概念的完整表達,其他什么的,都不必理會。一個類如果不好寫,往往意味著這個類的功能不專一,或者其概念不完整,這時,可以不要急著抽象,如果一個類有必要誕生,那么在代碼的編寫中,該類的抽象概念將一再重復出現(xiàn),猿猴對它的理解也越來越清晰,從而,水到渠成地把它造出來。所有非需求推動,非代碼推動的,拍著腦袋,想當然的造類行為,都是在臆造抽象,脫離實際生活的藝術(shù),最終將被淘汰。
類的設計,其著眼點在于用必要的數(shù)據(jù)來完整表達一個清晰的概念。而繼承,則是對類的概念進行細化,也就是分類,好比說生物下面開出來動物、植物這兩個子類,就是把生物分成動物、植物這兩類,繼承與日常生活的分類不太一樣,繼承的分類方式是開放式,根據(jù)需要,隨時可以添加新的子類別。整個類的體系,是一顆嚴格的單根樹,任何類只能有一個根類。從任何類開始,只能有一條路徑回溯到最開始的根類,java、C#中就是Object,所有的類都派生自Object,這是一棵大樹。單根系下,萬物皆是對象,這自然很方便,起碼,這就從語言層面上直接支持c++ std的垃圾any了。而由于java、C#完善的反射信息,拋棄靜態(tài)類型信息,也可以做動態(tài)語言層面上的事情,而c,c++的void*,所有的動態(tài)類型信息全部都在猿猴的大腦中。java平臺上生存著大把的動態(tài)語言,而且,性能都還很不錯。
相對很多語言來說,c++就是怪胎就是異數(shù),自有其自身的設計哲學,它是多根系的,它不可能也沒必要搞成單根系,當然,我們可以假設一個空類,然后所有的類都默認繼承自這個空類。c++的所有類組成一個森林,森林里的樹都長自大地。但是不管怎么說都好,只能允許單繼承,千萬不要有多繼承,這是底線,千萬千萬不能違背(當然,奇技淫巧的場合,就不必遵守這個戒條,多繼承千般不是,但是不可或缺,因為它可以玩出來很多花樣,并且都很實用很必要)。最起碼,單根系出來的內(nèi)存布局直觀可預測,一定程度上跨編譯器,只有良好的內(nèi)存布局,才有望良好的二進制復用。另外,父類對子類一無所知,不要引用到子類一丁點的信息,要保持這種信息的單向流動性。
在這種單根系的等級分明的階級體系下,一切死氣沉沉,沒有一點點的社會活力。顯然,只有同屬于同一父類的類別之間,才能共享那么一丁點可憐的共性。如果沒有接口搗亂,將是怎樣的悲劇,最好的例子,mfc,真是厲害,沒有用到接口,居然可以做出來嚴謹滿足大多數(shù)需要的gui框架,沒有接口,并不表示它不需要,因為mfc開了后門,用上了更厲害的玩意----消息發(fā)送,即便如此,mfc有些地方的基類還有依賴到子類,這就很讓人無語了。
c++下,類的設計絕對不對兒戲,一定要清楚自己想要的是什么,抽象出來的概念才不會變成垃圾。大而全的類,遠遠不如幾個小而專的細類。java,C#下的類開發(fā)很方便,但是粒度過大,把一攬子的東西都丟給你,強賣強買,反正只要類一定義,必然相應的就會出現(xiàn)一大坨完善的反射信息,而對象里面也包含了一些無關緊要的成員字段,而對象的訪問,也全部都是間接引用的訪問,雖然,現(xiàn)在計算機性能過剩,這些都無傷大雅。c++給了開發(fā)者最大的選擇,而搞c++的猿猴,基本上都智力過剩,對于每種選擇,都清楚其背后的代價以及所要到達的目的,所以雖然開發(fā)時候,存在心智包袱影響開發(fā)效率,但是,但內(nèi)心就不會存在什么性能包袱的負罪感。就個人而言,還是喜歡c++這種最高自由度的語言,有時候,對于內(nèi)存最細致的控制,可以得到更精簡的設計,這里無關運行性能,好比說,在c++中,只要內(nèi)存布局一致,即便是不同類型的對象,通過強制類型轉(zhuǎn)換來統(tǒng)一對待,進而做匪夷所思之事,好比COM里面,為了聚合復用,一個類,竟然可以針對同一個接口提供兩套實現(xiàn)方式。這種方便,在其他強類型語言中是不支持的。
某種意義上講,c++在面向?qū)ο笊咸峁┑恼Z言機制,就是為了方便地生成各種內(nèi)存布局,以及此內(nèi)存布局上所能支持的操作,虛函數(shù)用以生成一堆成員函數(shù)指針,繼承則用以方便地生成一坨成員字段,……。所以,c++的面向?qū)ο缶褪敲嫦騼?nèi)存布局地設計,而多繼承、虛繼承、模板這些鬼東西很容易就導致內(nèi)存布局的失控,不過,如果使用得當,卻又有鬼斧神工之奇效,創(chuàng)造出來其他語言所沒有的奇跡。真的,論動態(tài)行為藝術(shù),任何語言在c++這個大人面前都是幼兒園里的小學生。
為了引出接口,本座花大力氣做科普。這也沒辦法,因為類雖然是基礎,但是靜態(tài)面向?qū)ο蟮木A,全部都在接口上。只有清晰明確類的功能職責,才能理解接口的必要性以及其多樣性。那么,可不可以只有接口,沒有類的??梢?,就好像com那樣子,而代價是,使用起來,各種不方便。這個世界,從來就不存在包治百病之萬能藥。什么事情都能做的意思就是什么都做不好。
相關文章
Visual Studio 如何創(chuàng)建C/C++項目問題
這篇文章主要介紹了Visual Studio 如何創(chuàng)建C/C++項目問題,具有很好的參考價值,希望對大家有所幫助。如有錯誤或未考慮完全的地方,望不吝賜教2023-02-02C++調(diào)用matlab引擎實現(xiàn)三維圖的繪制
這篇文章主要為大家詳細介紹了C++如何調(diào)用matlab引擎實現(xiàn)三維圖的繪制,文中的示例代碼講解詳細,對我們學習C++和Matlab有一定的幫助,需要的可以參考一下2022-12-12