1樓：驕傲的魚
解耦，簡化依賴關係。
乙個best practice: 將類的構建和方法呼叫，所需的引數型別設定成介面，可以大大降低UT的成本。
2樓：DotneterBruce
相較於樓上的人千篇一律的告訴你這是乙個「規範」,"合同"的概念的時候，我更希望你可以去嘗試寫一些簡單的框架或者重構一下簡答的業務，你需要嘗試去抽離出抽象物件，而這個抽象物件就是介面，有人說這不是抽象類嗎？部分語言已經就沒有介面的概念了，因為抽象類和介面除了用法的區別，本質上是沒有什麼區別的。
當你使用了所謂的「多型」去設計程式，「依賴注入」去管理某型別的物件的時候，你會覺得你自己已經非常了解介面這個型別了。
3樓：卋罖
介面定義了所有類繼承介面時應遵循的語法合同。介面定義了語法合同"是什麼"部分，派生類定義了語法合同"怎麼做"部分。
介面定義了屬性、方法和事件，這些都是介面的成員。介面只包含了成員的宣告。成員的定義是派生類的責任。介面提供了派生類應遵循的標準結構。
介面使得實現介面的類或結構在形式上保持一致。
抽象類在某種程度上與介面類似，但是，它們大多只是用在當只有少數方法由基類宣告由派生類實現時。
4樓：w甜甜
乙個類繼承了某個虛擬類，意味著它是某個東西比如邊牧繼承了「人」，哈士奇繼承了「狗」
乙個是人乙個是狗
乙個類繼承了某個介面意味著其有某個功能
但是不論是人是狗應該都實現了乙個IEat介面，那個狗，人，都有「吃」這個功能
5樓：NMSAzulX
你教弟弟做菜，你說他做。你就是介面，他負責實現。
如果你說放鹽，弟弟1放1勺，弟弟2放2勺，這兩個弟弟的實現介面的內容不同，做出的菜味道也不一樣，但沒有你他們就做不出來。
6樓：6號鹹魚
介面的意義是可以讓不同的型別具有相同的操作標準。就像插頭，兩孔是乙個介面，實現這個介面就可以插到兩孔的插座上，三孔是另乙個介面。如果同時實現這兩個介面就可以既插到兩孔插頭也可以插到三孔插頭。
7樓：jack
從具體的類的開發，會發現一些相同的屬性方法，然後封裝基類，封裝公共的方法，會有一些空方法體，加抽象關鍵字修飾，為純虛方法，進一步抽象為抽象類，抽象類裡的行為方法進一步抽象為一組介面，就成為介面。一層一層的抽象，可以解耦合，提高程式的擴充套件。
8樓：ZP.ST
我理解的介面意義是：介面類裡面定義了一堆沒有實現的方法，在這個介面的派生類中就要實現這些方法。因此介面可以理解為規定了一堆的行為，所有派生類都要求有此行為，但是行為的具體實現由派生類決定。
9樓：DuaiHan1020
介面的本質意義：
功能上：介面是乙個契約，為不同模組的溝通提供標準。（完全字面含義足矣）
它的性質：暴露功能而隱藏實現。
如果要說到C#介面意義，那就要說C#的介面，相比介面的本質定義，有什麼不一樣。那就是具體語言環境中介面的意義：
1.允許多重繼承/實現
2.通用性（struct/class）
3.作為純標準被實現（而不作為類布局）
[其他細節請補充...]
說白了這些都是語言細節，依賴於實現，不依賴於「介面」這個詞本質，當然正常都會遵循介面的本質。
為什麼要寫第3條，這條其實就是介面的本質。--因為有個不爭氣的C++。
C#介面是「超越」C++介面的乙個存在，（C++其實沒有「介面」，C++的「介面」就是虛基類）。
C#介面，使得處於繼承鏈上每乙個類都可以擁有同樣處於繼承鏈上的一系列介面，而不發生重複的方法繼承/實現，當然這只是在隱式實現的情況下所說。而C++就比較尷尬，需要應對每個基類相同簽名的方法。
10樓：趙阿山
介面就是規格（Specification），它只定義方法(Methods)和屬性(Properties)，但絕對不能有任何具體實現(Implementation)，它的成員全部是公有型別(Public)，不能定義私有(Private)和保護(Protected)類成員。
我來擴充套件一下您的問題，您是否更關心介面的用法上？介面多用於軟體工程上，如果是個人專案，介面的定義完全是可選的，個人感覺很多時候甚至是一種重複和浪費。如果是小型專案，可以直接使用型別的繼承(Inheritance)和擴充套件(Extension)，完全不需要介面。
泛型(Generalization)和方法過載(Override)/過載(Overload)在C#中更加靈活和方便。
如果涉及到需要執行時型別識別(RTTI - Runtime Type Identification)或依賴注入(DI - Dependency Injection)的專案時，介面的定義也是必須的，負責會是一種災難。因為我個人並不推薦在生產環境中使用反射(Reflection)技術來做型別識別。（這裡可能會引起爭論，個人覺得對介面進行DI好過具體的實現類，可以避免很多不確定性，是一種好的設計規範）。
一般來說，我們在建立專案樹的時候會把所有介面放入乙個Assembly和網域名稱裡，具體實現類卻不會跟界麵包混放，這樣方便將來的部署和版本演進和控制。
最後，我的意思不是說介面類無用，而是說它更傾向於應用在團隊專案中或者商業專案中。對於小型或內部專案，不要被它所羈絆。
11樓：若去
舉例太多不如自己設計乙個架構，定義方便的操作呼叫，其實對小白意義不大。
簡單來說就是為了方便程式設計，因為這個原因才設計介面，而不是有了介面才程式設計。
12樓：Dark Efl
個人理解
介面就是一種約定或者協議，如果你繼承了此介面，也就是說你要遵循規定實現協議，至於具體你怎麼去實現的，它並未做規定。介面和類相似，類是對物件的抽象，介面是對物件所擁有的方法的抽象。
13樓：miccio
介面就是讓，呼叫你方法的人不要看你寫的那一坨(所以強調介面呼叫)。第二個目的是讓你別什麼東西都寫乙個類裡面。如果你願意每個方法都寫乙個介面然後實現它。
然後你再去體會介面的作用，再去看樓上各位的回答。
14樓：
可以思考一下多型的意義是什麼，自然就明白介面的意義是什麼了。
介面的真正目的是引用乙個物件所在的記憶體位址（該位址存放了該物件）。只是介面引用物件的要求是"被引用的物件必須包含它對應介面裡面的方法或屬性的定義"。實際上介面有點像抽象類，只是介面解決了乙個類無法繼承多個類的缺陷。
15樓：Hex
簡單的來說，介面其實就是物件導向設計裡面的一種Can Do關係，這是一種對於能力的抽象，而非傳統意義的子類和父類的Is A關係。
設計初衷是這樣的，但因為基類只能有乙個的規定，因此在實踐中實際上衍生出來了一些替代多基類的作用。
16樓：
舉例乙個用法
void 插座（插頭規格插頭）
那麼插頭規格就是「介面」，只要符合規格的插頭（就是符合介面規格的object）都可以插進來（作為引數傳入）
17樓：孤狐無悔
從兩個方面來解釋：
介面是一種約定（契約）。
只要類符合介面的定義（具有介面需要的所有方法和屬性），那麼所有能夠用於這個介面的事物，就能夠用於這一類。
舉例來說。C#中已有現成的排序方法。但是已有系統排序方法並不知道怎樣處理使用者自己寫的類。那麼使用者就必須要自己寫排序方法麼？
這時介面就有用了。排序實際上並不需要知道類的細節，只要知道類的兩個例項怎樣比較大小即可。「怎樣比較大小」就是這個介面的約定。
翻譯成程式語言就是：如果想要使用系統已有的排序方法，要求使用者類實現ICompareable介面。
介面用於解決多型繼承的問題。
「類」是物件導向程式設計的核心，對應現實世界就是「分類」。然而分類不是一件容易的事情，一件事物同時屬於多個類別，是經常發生的事情。
邏輯上的描述就是：A是B，A是C，B不是C，C不是B。
程式設計中，A需要同時繼承自B和C，這就叫多型繼承。
然而多型繼承容易引發命名衝突問題，所以大多數現代程式語言都不支援多型繼承。
介面就可以在語義上代替多型繼承，在功能上代替多型繼承的一部分。
例如，電燈，即使電器，也是照明裝置，還可以是一件藝術品。這就相當於三個介面。具體要用其中的哪個作為基類，主要是看使用環境，
18樓：張齊天
介面這個機制發明出來是為了抽取出一系列的操作行為，讓只有操作行為的物件就能夠執行一定行為的一種機制，實際上就是封裝的一種模式。
物件本身是無法防止「只有」這一層含義的，因為它自帶了很多方法。如果我們試著對這個物件抽取出一些固定的操作，那麼所有只要帶這些操作的物件就可以用這個方法了。
舉個例子，我有乙個列表物件，這個列表物件包含一大堆的資料資訊。但我在嘗試把這個列表物件作為引數傳遞到函式裡的時候，就會出現乙個隱藏的 bug：
public
static
int?
GetMax
(this
List
list
)這個方法看起來沒啥大不了的，就是取列表裡面最大的那個數字。不過整個列表讀取的過程都沒有修改資料。如果我直接傳入 List 物件過去，從語法層面就無法防止你修改資料這乙個行為。
萬一我不小心改掉了資料，編譯器也不管你，這不是就出現安全錯誤了嘛。
我們發現，List 物件實現了乙個叫做 IReadOnlyList 的介面，開啟介面你就可以看到，這個介面只有取值的相關行為。確實，從這個方法裡看到我們只用了這個列表的索引器和 Count 屬性：索引器是 IReadOnlyList 介面裡唯一包含的成員，而 Count 則是該介面繼承下來的「基介面」IReadOnlyCollection 介面裡的唯一包含成員。
我們確實只用了這兩樣東西就可以搞定，那麼為了防止隱藏的錯誤和漏洞出現，我們乾脆就直接把這個介面型別當引數傳遞過來，來表達「在方法裡我不需要用別的東西，Count 和索引器就足夠我能完成整個執行流程了」。於是，方法只需要改一改引數型別即可：
public
static
int?
GetMax
(this
IReadOnlyList
list
)這樣，你嘗試對 list 修改內容，不管你怎麼寫都會出現編譯器錯誤。編譯器它現在知道你只取值，不會用別的功能了，因此 Intellisense 不會給你更多的提示，編譯器也會告知你無法使用別的、IReadOnlyList 介面裡不存在的成員。
所以，介面的第乙個存在的意義是，防止使用者亂用物件，把物件的訪問內容最小化，來盡量避免隱藏的問題。
那麼，肯定有人會說，我用抽象類有時候也可以完成啊。比如，我現在要對乙個圖形物件計算面積。顯然，我們可以實現一些基本的圖形的對應類，然後都從 Shape 類進行派生。
Shape 僅包含了 Area 屬性。我們在獲取結果的時候，也完全可以直接 .Area 來獲取。
從執行時，我們也可以直接從實際型別的角度確定結果。那麼看起來好像抽象類也可以解決問題。
是的，抽象類在一定程度上可以解決這樣的問題，但介面還有乙個好處就是不需要考慮繼承。前文我們表達的 IReadOnlyList 介面，除了 List 是實現了，陣列也是實現了的哦。陣列預設從 Array 類派生，它和 List 完全就不是一路人，但由於它們都實現了相同的介面型別，所以我們使用介面可以更大程度上保證物件能夠使用；限定死了的話，List 可以用，陣列又不能用了；或者陣列能用的時候，List 它又不能用了。
乙個介面不就解決了。
這也是為什麼介面和抽象模擬較類似，但又不一樣的原因。抽象類用於給子類擴充套件用，提供一些基本的操作，不允許例項化，這一切的一切都是為了幹嘛呢？可以從 Shape 這個例子裡看出來，Shape 派生出去的類，都是 Shape 的子類；而派生的類表達出來、理解出來就是「我繼承了乙個圖形的類，那麼我的這些子型別都應該都是圖形才對」，因此，抽象類解決了「是什麼」的關係。
比如「學生是人，老師也是人」，那麼繼承關係應該是 Person 類作抽象類，而 Student 和 Teacher 類都是它們的乙個子型別；而介面則並不是為了這樣的東西而誕生的。我們從這個 List 取最大值的這個例子裡來看，介面給了很少的成員，當你實現了它們，這就意味著「這個型別可以完成你給的這些功能了」。那麼當我只需要這些功能的時候，就可以隱藏基本的型別來達到封裝的作用，避免隱藏的問題，所以它更側重的是「能做什麼」。
我能吃飯、能跑步、能睡覺，那麼每乙個方法都放在不同的介面裡，而讓「我」這個類全部實現它們。到時候，如果我要辦一場比賽，要獲取一群「能吃飯」的人誰吃得快，那麼傳入一大堆的 Person 型別未免有一點龐大，也不是很合理；相反，我只需要 IEattable 的介面型別的陣列，或者列表物件，應該就足夠了。
C 如何入門程式介面的編寫
劉Hongye 入口的問題估計就是程式怎麼執行，視窗如何畫出的問題。也被困惑了很長時間。上面回答中提到的書基本解決了這個問題。但窮究細節，即使當時明白了，過段時間不用就生疏了。所以還是知道了大概方向就可，如用到臨時查文件就行。關於介面庫，en.wikipedia.org wiki widget to...
Java中介面繼承介面有什麼實際意義？
blues 我覺得繼承的意義在於便於理解吧，介面可以分為寬介面和窄介面，你試想把所有介面中的方法都放到乙個介面中，直接讓類實現這個介面不也可以起到同樣效果嗎，為什麼還要細分呢？但閱讀起來我們沒法知道這個類到底要幹嗎，介面窄化可以明確這個介面的功能，更容易理解和維護 Spongecaptain 類實現...
Linux 圖形介面的顯示原理是什麼？
Michael002 安裝好桌面和依賴的圖形庫後裝乙個遠端桌面Server 如xrdp或者vncserver等，然後在Windows上用對應的客戶端即可顯示桌面 實際上是跑在本地的遠端桌面 另外VSCODE現在支援WSL了，裝幾個外掛程式就可以輕鬆訪問WSL檔案和使用WSL的開發環境進行編譯除錯了，...