類的設(shè)計在于用恰到好處的信息來完整表達一個職責清晰的概念，恰到好處的意思是不多也不少，少了，就概念就不完整；多了，就顯得冗余，累贅，當然特例下，允許少許的重復，但是，這里必須要有很好的理由。冗余往往就意味著包含了過多的信息，概念的表達不夠精準，好比goto，指針，多繼承這些貨色，就是因為其過多的內(nèi)涵，才要嚴格限制其使用。好像，more effective c++上說的，class的成員函數(shù)，應該是在完整的情況下保持最小化。但是，這里我們的出發(fā)點，是成員數(shù)據(jù)的完整最小化。

最小化的好處是可以保持概念最大的獨立性，也意味著，可以用最小的代價來實現(xiàn)這個概念，也意味著對應用層的代碼要求越少，非侵入式？好比c++11 noexcept取代throw()，好比從多繼承中分化出來接口的概念，好比不考慮多繼承虛繼承的普通成員函數(shù)指針。又比如，如果不要求只讀字符串以0結(jié)束，那么就可以把只讀字符串的任何一部分都當成是只讀字符串。類的對外功能固然重要，但是，類不能做的事情，也很重要。

首先是要有清晰的概念以及這個概念要支持的最基本運算，然后在此基礎(chǔ)上組織數(shù)據(jù)，務(wù)求成員數(shù)據(jù)的最小化。當然，概念的產(chǎn)生，并非拍著腦袋想出來的，是因為代碼里面出現(xiàn)太多那種相關(guān)數(shù)據(jù)的次數(shù)，所以就有必要把這些數(shù)據(jù)打包起來，抽象成一個概念。好比說，看到stl算法函數(shù)參數(shù)到處開始結(jié)束的迭代器，就有必要把開始結(jié)束放在一起。比如說，string_view的出現(xiàn)，這里假設(shè)其字符存儲類型為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ù)可以通過其他成員函數(shù)來實現(xiàn)，就意味著這個函數(shù)應該趕出類外，作為全局函數(shù)存在。當然，這也不是死板的教條，有些很特殊的函數(shù)，也可以是成員函數(shù)，因為成員函數(shù)的使用，確實很方便。

可能會有疑惑，感覺所有的成員函數(shù)其實都可以是全局函數(shù)?；蛘哒f，我們可以對每一個成員字段都搞一對set、get的函數(shù)，那么所有的其他成員函數(shù)就可以是全局函數(shù)的形式，很容易就可以遵守最小完整化的原則。當然，這是明顯偷懶，拒絕思考的惡劣行為。與其這樣，還不如就開放所有的成員字段，那樣子就落入c語言的套路了。所以的法論是，一個函數(shù)，這里假設(shè)是全局函數(shù)，如果它的實現(xiàn)必須要訪問到成員字段，不能通過調(diào)用該類的成員函數(shù)（一般不是get，set）來達到目的，或者，也可以強行用其他函數(shù)來完成任務(wù)，但是很麻煩，或者要付出時間空間上的代價，那么就意味著這個函數(shù)應該是該類的成員函數(shù)。

類的設(shè)計，就是必不可少的成員字段和必不可少的成員函數(shù)，它們一起，實現(xiàn)了對類的原始概念的完整表達，其他什么的，都不必理會。一個類如果不好寫，往往意味著這個類的功能不專一，或者其概念不完整，這時，可以不要急著抽象，如果一個類有必要誕生，那么在代碼的編寫中，該類的抽象概念將一再重復出現(xiàn)，猿猴對它的理解也越來越清晰，從而，水到渠成地把它造出來。所有非需求推動，非代碼推動的，拍著腦袋，想當然的造類行為，都是在臆造抽象，脫離實際生活的藝術(shù)，最終將被淘汰。

類的設(shè)計，其著眼點在于用必要的數(shù)據(jù)來完整表達一個清晰的概念。而繼承，則是對類的概念進行細化，也就是分類，好比說生物下面開出來動物、植物這兩個子類，就是把生物分成動物、植物這兩類，繼承與日常生活的分類不太一樣，繼承的分類方式是開放式，根據(jù)需要，隨時可以添加新的子類別。整個類的體系，是一顆嚴格的單根樹，任何類只能有一個根類。從任何類開始，只能有一條路徑回溯到最開始的根類，java、C#中就是Object，所有的類都派生自O(shè)bject，這是一棵大樹。單根系下，萬物皆是對象，這自然很方便，起碼，這就從語言層面上直接支持c++ std的垃圾any了。而由于java、C#完善的反射信息，拋棄靜態(tài)類型信息，也可以做動態(tài)語言層面上的事情，而c，c++的void*，所有的動態(tài)類型信息全部都在猿猴的大腦中。java平臺上生存著大把的動態(tài)語言，而且，性能都還很不錯。

相對很多語言來說，c++就是怪胎就是異數(shù)，自有其自身的設(shè)計哲學，它是多根系的，它不可能也沒必要搞成單根系，當然，我們可以假設(shè)一個空類，然后所有的類都默認繼承自這個空類。c++的所有類組成一個森林，森林里的樹都長自大地。但是不管怎么說都好，只能允許單繼承，千萬不要有多繼承，這是底線，千萬千萬不能違背（當然，奇技淫巧的場合，就不必遵守這個戒條，多繼承千般不是，但是不可或缺，因為它可以玩出來很多花樣，并且都很實用很必要）。最起碼，單根系出來的內(nèi)存布局直觀可預測，一定程度上跨編譯器，只有良好的內(nèi)存布局，才有望良好的二進制復用。另外，父類對子類一無所知，不要引用到子類一丁點的信息，要保持這種信息的單向流動性。

在這種單根系的等級分明的階級體系下，一切死氣沉沉，沒有一點點的社會活力。顯然，只有同屬于同一父類的類別之間，才能共享那么一丁點可憐的共性。如果沒有接口搗亂，將是怎樣的悲劇，最好的例子，mfc，真是厲害，沒有用到接口，居然可以做出來嚴謹滿足大多數(shù)需要的gui框架，沒有接口，并不表示它不需要，因為mfc開了后門，用上了更厲害的玩意----消息發(fā)送，即便如此，mfc有些地方的基類還有依賴到子類，這就很讓人無語了。

c++下，類的設(shè)計絕對不對兒戲，一定要清楚自己想要的是什么，抽象出來的概念才不會變成垃圾。大而全的類，遠遠不如幾個小而專的細類。java，C#下的類開發(fā)很方便，但是粒度過大，把一攬子的東西都丟給你，強賣強買，反正只要類一定義，必然相應的就會出現(xiàn)一大坨完善的反射信息，而對象里面也包含了一些無關(guān)緊要的成員字段，而對象的訪問，也全部都是間接引用的訪問，雖然，現(xiàn)在計算機性能過剩，這些都無傷大雅。c++給了開發(fā)者最大的選擇，而搞c++的猿猴，基本上都智力過剩，對于每種選擇，都清楚其背后的代價以及所要到達的目的，所以雖然開發(fā)時候，存在心智包袱影響開發(fā)效率，但是，但內(nèi)心就不會存在什么性能包袱的負罪感。就個人而言，還是喜歡c++這種最高自由度的語言，有時候，對于內(nèi)存最細致的控制，可以得到更精簡的設(shè)計，這里無關(guān)運行性能，好比說，在c++中，只要內(nèi)存布局一致，即便是不同類型的對象，通過強制類型轉(zhuǎn)換來統(tǒng)一對待，進而做匪夷所思之事，好比COM里面，為了聚合復用，一個類，竟然可以針對同一個接口提供兩套實現(xiàn)方式。這種方便，在其他強類型語言中是不支持的。

某種意義上講，c++在面向?qū)ο笊咸峁┑恼Z言機制，就是為了方便地生成各種內(nèi)存布局，以及此內(nèi)存布局上所能支持的操作，虛函數(shù)用以生成一堆成員函數(shù)指針，繼承則用以方便地生成一坨成員字段，……。所以，c++的面向?qū)ο缶褪敲嫦騼?nèi)存布局地設(shè)計，而多繼承、虛繼承、模板這些鬼東西很容易就導致內(nèi)存布局的失控，不過，如果使用得當，卻又有鬼斧神工之奇效，創(chuàng)造出來其他語言所沒有的奇跡。真的，論動態(tài)行為藝術(shù)，任何語言在c++這個大人面前都是幼兒園里的小學生。

為了引出接口，本座花大力氣做科普。這也沒辦法，因為類雖然是基礎(chǔ)，但是靜態(tài)面向?qū)ο蟮木A，全部都在接口上。只有清晰明確類的功能職責，才能理解接口的必要性以及其多樣性。那么，可不可以只有接口，沒有類的。可以，就好像com那樣子，而代價是，使用起來，各種不方便。這個世界，從來就不存在包治百病之萬能藥。什么事情都能做的意思就是什么都做不好。