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