如果說，類的設(shè)計思路，是以數(shù)據(jù)為基礎(chǔ)的縱向組織結(jié)構(gòu)，只有唯一的分類方式，有相同基類的，就意味著其相似性，共同點都體現(xiàn)在基類上；那么，接口就是以功能以性質(zhì)從橫向上，來看待類的相似性，并且存在無數(shù)的橫向視角（否則就失去意義）。
靜態(tài)面向?qū)ο笳Z言，這里不考慮template，c++的template是鴨子類型，本質(zhì)上，c++編譯期就是一個功能完備的動態(tài)語言。代碼上的復(fù)用就只能以基類為粒度來進行，比如，函數(shù)int fn(Base* bb)，只有Base的子類，才有資格成為函數(shù)fn的會員。函數(shù)fn之所以聲明其變量bb的類型為Base，就是為了使用類型Base里面的一些東西，一般就是成員函數(shù)（對于清教徒來說，不是一般，而是必然）。假如，函數(shù)fn的實現(xiàn)中，就用到Base的幾個成員函數(shù)，比如說f1，f2，…，fn。換句話說，雖然fn(Base* bb)表面上要求一定要Base的子孫后代才能擔(dān)當(dāng)重任，但實際上，只要別的class，不必跟Base有半毛錢關(guān)系，只要這個class里面支持f1，f2，…，fn這些操作，那么原則上他就有資格到fn里面一游。天下唯有德者居之，不必講究什么貴族。但是，在沒有接口的等級森嚴(yán)的封建社會里面，就算你有驚天之地之能，就因為你沒有某種高貴的血統(tǒng)，所以你就不行。
在單根類的王國中，所有對象都源于Object，也可以通過反射，通過函數(shù)名字運行時獲取串f1，f2，fn等成員函數(shù)，然后再人肉編譯器關(guān)于參數(shù)信息和返回值類型，以擺脫Base的類型桎梏，但是，估計也只有在最特殊的時候，才會這樣玩。這樣玩，簡直置編譯器的類型檢查于不顧，靜態(tài)語言就是要盡可能的挖掘編譯器類型檢查的最后一絲潛力。
接口的出現(xiàn)，就在縱向的類型關(guān)系上撕開一道道口子，從而盡最大限度釋放對象的能力。時代不同了，現(xiàn)在接口IBase里面聲明f1，f2，fn等函數(shù)，然后函數(shù)fn的入?yún)?/span>IBase，也即是 int fn(IBase* bb)，以明確表示fn里面只用到IBase的函數(shù)，語義的要求上更加精準(zhǔn)。然后，任何class，只要其實現(xiàn)了接口IBase，就有資格被fn接納，不必再是Base之后了。所以說，要面向接口編程，就是要面向功能來搬磚，選擇的樣本空間就廣闊了很多。接口是比具體類型要靈活，但不意味著所有的地方就必須只出現(xiàn)接口，class類型就沒用了，當(dāng)然不是，有些地方就很有必要用具體類型，比如說string類型，比如說復(fù)數(shù)這些，就必須明確規(guī)定具體類型，無須用到接口的靈活性。總之，還是那句話，沒有銀彈，具體問題具體分析。
使用對象，其實就是在使用對象的成員函數(shù)，那么，接口也可以看成是成員函數(shù)的粒度管理工具。所以，接口就表示了一批成員函數(shù)，需要用一批成員函數(shù)的時候，用接口最為方便。坊間有一些犯virtual恐懼癥的c++猿猴，高高興興地用一批function代替接口，罔顧其性能（時間空間）的損失、使用上的不便，哎！面向?qū)ο笫菑娪辛Φ某橄蠊ぞ撸戎诿嫦蜻^程，函數(shù)式，有著獨特的優(yōu)點，反正代碼構(gòu)架上，優(yōu)先使用面向?qū)ο螅^不會錯。而面向?qū)ο螅捅厝换乇懿涣私涌凇?/span>
坊間支持面向?qū)ο笳Z言中對接口的支持，當(dāng)以rust，scala的trait機制最為令人喜歡，非侵入式啊，自然狗語言的也還好，但是，本人最反感，反正，狗語言上一切獨有特性，本人都本能地毫無理由排斥。自然，java、C#或者c++的多繼承，最為笨拙，呆板。
java、C#里面，類能夠?qū)崿F(xiàn)的接口，在類的定義中，就已經(jīng)定下來了。類一旦定義完畢，與該類相關(guān)的接口就定下來，鐵板一塊，密不透風(fēng)，不能增不能減也不能改。你明明看到一個類就已經(jīng)實現(xiàn)了某個接口的所有方法（函數(shù)名字和簽名一模一樣），但就是因為該類沒有在定義中明確說明實現(xiàn)該接口，所以編譯器就死活不承認該類實現(xiàn)這個接口。只能用適配器模式，也即是新造一個class，實現(xiàn)該接口，包含舊類的對象，將接口的所有方法都委托給對象的相應(yīng)函數(shù)來做。java的繁文縟節(jié)就是這樣來的，規(guī)規(guī)矩矩，畢恭畢敬，一步一個腳印。更麻煩的是，每次傳遞參數(shù)都要new一個適配器對象來滿足參數(shù)的要求，這是最讓人難受的地方。
java、C#的這種接口機制，實在與現(xiàn)實對不上號，真是找不到任何原型，任何類型的物品，就算是新造的東西，我們都不可能一開始就窮盡它的所有性質(zhì)所有功能。就算是藥物，都有可能是歪打正著的功能，比如偉哥的功能，是其研發(fā)階段中意想不到的。java、c#的這種接口，會很干擾類的完整最小化的設(shè)計原則，進而加大類的設(shè)計難度。當(dāng)然，它也非一無是處，起碼，類支持多少接口，一眼就看出來了，毫無疑義。問題是，接口這種東西，本質(zhì)上就應(yīng)該是不確定的橫向視角來考察類的關(guān)系。java、C#下的接口問題，大大限制了接口的使用場合。
其次，繼承時，子類就繼承了基類的所有東西，包括其實現(xiàn)的接口。但是，有些時候，子類并不想擁有父類的某些接口。比如，鴨子應(yīng)該算是鳥類的一個子類，而鳥類支持“會飛”這個接口，但是鴨子顯然不會飛，也就是說，雖然鴨子包含了鳥類的所有數(shù)據(jù)，但是它不擁有會飛這個功能。對此，我們希望在編譯期間，就能在要求會飛的場合下，傳鴨子對象進去時，編譯器報錯。但是，對此，只能在運行中報錯，而且，還是在調(diào)用會飛的成員函數(shù)里面才報錯。原則上，編譯器是可以知道鴨子不會飛這個概念的，但是，由于java、C#的接口控制粒度單一，滿足不了這種要求。
再次，接口不能組合，比如說，函數(shù)fn的參數(shù)，假設(shè)名字為pp，pp要求同時實現(xiàn)接口IA，IB。對此，java、C#中是沒有語法滿足這種多個接口的要求。遇到這種需求時，只能用強制類型轉(zhuǎn)換，先隨便讓參數(shù)類型為IA或者IB，然后在必要時，強制轉(zhuǎn)換為另外的類型，只能在運行時報錯。又或者是，新造一個接口IAB從IA，IB上繼承，然后函數(shù)fn的參數(shù)pp的類型為IAB，但是這樣，依然存在不足，假如某個類實現(xiàn)IA和IB，但是沒有表明它實現(xiàn)IAB，那么還是不能滿足參數(shù)的要求。接口組合的問題，不管是go、rust，都沒有很好的支持，只能到運行時類型轉(zhuǎn)換才能發(fā)生。
最重要的是，這種接口機制違反了零懲罰的機制。就以c++為例來說明，就只論接口好了，也即是只有虛函數(shù)但是沒有成員字段的基類。為了方便描述，還是舉例子。
struct IA {virtual void fa() = 0;};
struct IB {virtual void fb() = 0;};
struct Base{…};
struct Derived : public Base, public IA, public IB{…};
接口IA有虛函數(shù)，里面就要有一個指針指向其虛函數(shù)表，所以其內(nèi)存占用就是一個指針的大小；同理，IB也如此。表面的意思是Derived實現(xiàn)了接口IA，IB，實際上，在C++中，接口實現(xiàn)就是繼承，也就是說每個Derived的實例都要包含IA，IB里面的數(shù)據(jù)，指向?qū)?yīng)虛函數(shù)表的指針字段，也即是有兩個指針。這里做不到零懲罰的意思，是說， Derived為了表明自己有IA、IB的能力，每個對象付出了兩個多余的內(nèi)存指針空間的代價，即便是對象不需要在IA、IB的環(huán)境下使用，這個代價都避免不了。零懲罰抽象，就是要用到的時候才付出代價，哪怕這個代價可以大一點。用不到時，則不必消耗哪怕一點點空間時間上的浪費。空間上浪費的問題不在于節(jié)省內(nèi)存，而在于喪失了精致的內(nèi)存布局，進而影響到二進制的復(fù)用。這一點，非侵入式接口就不用也沒辦法在對象身上包含其所支持的所有接口的虛函數(shù)表指針，因為類型定義完畢，后面還可能在其上添加新的接口實現(xiàn)。
而由這幾點問題引申出來的其他缺陷就不必提了。反正，C++，包括java，C#的這種接口機制最不討人喜歡了。
至于狗語言的鴨子接口，有時會出現(xiàn)函數(shù)名字沖突的小問題，稍微改一下名字就好了。主要是這種接口機制只要一個類包含了某個接口的所有成員函數(shù)，就隱式認為它實現(xiàn)了這個接口。這里會有暗示（誤導(dǎo)，誘惑），就是定義類的成員函數(shù)時，會有意或者無意地遷就現(xiàn)有接口的成員函數(shù)，同樣，聲明接口成員函數(shù)時，也會有意無意地往現(xiàn)有類的成員函數(shù)上靠。從而導(dǎo)致真正函數(shù)的語義上把控不夠精準(zhǔn)。并且，這種機制太過粗暴，萬一這個類雖然支持某個接口的所有函數(shù)，但是并不一定就意味著它就要實現(xiàn)這個接口了。狗語言最令人反感之處就是各種自作聰明自以為是的規(guī)定。當(dāng)然，由于狗語言的成員函數(shù)可以非侵入式，這個問題造成的不便一定程度上有所減輕，但是，說實在，就連非侵入式的成員函數(shù)，本座也不太喜歡了。另外，僅僅從語言層面上，不借助文檔，很難知道一個類到底實現(xiàn)那些接口，某個接口被那些類實現(xiàn)，java、C#的接口在這一點的表現(xiàn)上就很卓越。其實，本座反感狗語言的最大原因還是因為狗粉，相比之下，java粉、php粉等粉，就可愛多了。
rust以trait形式實提供的接口機制就不多說了，語法形式上簡潔漂亮，基本上夢寐以求的接口樣子就是這樣子的了。
以上語言的接口，全部屬于靜態(tài)接口，也即是類型所實現(xiàn)的接口在編譯期間就全部定下來了，運行時就不再有任何變化。但是，如果對象一直在變化，好比生物，就說人類好了，有嬰兒少年青年中年老年死亡這些變化階段，顯然每一階段的行為能力都大不一樣，也擁有不同頭銜，不同身份。也就是說，現(xiàn)實中，活生生對象的接口集合并非一成不變，它完全可以現(xiàn)在就不支持某個接口，高興時候又可以支持了，不高興時就又不支持了，聾了就聽不到聲音，盲了就看不見，好似消息發(fā)送那樣子，顯然以上語言是不支持這種動態(tài)需求的接口的。
另外，com的接口查詢雖然發(fā)生在運行時，但是，com的規(guī)范，比如對稱性、傳遞性、時間無關(guān)性等規(guī)則，硬是把com從動態(tài)接口降維到靜態(tài)接口，這也可以理解，因為動態(tài)接口的應(yīng)用場景真的并不多。這些都沒什么，com最根本的問題，還是在于接口要承載類的功能，當(dāng)然，這樣也有好處，比如語言的無關(guān)性。IUnknown的三大成員函數(shù)分明就是類的本職工作，AddRef，Release管理對象的生命周期，Query查詢所要的接口。生命周期由對象粒度細化為接口粒度，就顯得太瑣碎，要謹(jǐn)記好幾條規(guī)則，要小心翼翼地應(yīng)付AddRef，Release的函數(shù)調(diào)用，智能指針也只能減輕部分工作量，這就是粒度過小帶來的痛苦。而Query的本質(zhì)就是對象所實現(xiàn)接口集合，這是對象的本分工作，現(xiàn)在搞成接口與接口之間的關(guān)系。由于接口越俎代庖，承接了類的職責(zé)，就要求每個接口都要繼承IUnknown，本來接口之間就應(yīng)該沒什么關(guān)聯(lián)性的才對，還導(dǎo)致com的實現(xiàn)以及使用，在c++下，非常繁復(fù)麻煩，令人頭皮發(fā)麻。所以說，類與接口，一體兩面，誰也不能代替誰。
---------------------------------------------------------------------------------------------------------------------------------
備注：現(xiàn)實世界中，一種或幾種功能就能推導(dǎo)出來其他性質(zhì)，對應(yīng)到接口中，就是如果對象實現(xiàn)某些接口，就表示它能實現(xiàn)另外其他接口。目前的語言，也就是接口繼承，子接口繼承父接口，那么，如果一個類實現(xiàn)了子接口，就表示它也實現(xiàn)了父接口，語言明面上只支持這種接口的蘊含關(guān)系。對于其他的蘊含情況，只能用適配器來湊數(shù)，而在非侵入式接口中，其語言形式就顯得更加的累贅，這一點，在java上尤為突出。其實，說到底，適配器模式只是彌補語言不支持接口蘊含機制的產(chǎn)物。