C 我應該在什麼時候使用介面？

介面用於架構。

例如，要製作乙個程式，你需要乙個網路模組，但你還沒有實現它。

然後先定義乙個網路介面，比如 inet，定義它等，子介面可以定義虛函式，這樣我們就不必等網路模組寫完了再寫其他模組。

再比如聊天，我先寫主控：

inet = new net（） 不適用於該介面。

iui = new ui()

oninetreceive

onlocalchat

onlocalchat（str）

oninetreceive(str)

這樣，我就可以讓任意兩個人給我ui和net實現。

C 是基於事件的程式，而 C++ 是基於訊息的。 事件是一種特殊的委託，委託指向的函式通常是乙個介面。

讓我告訴你我自己的經歷：

介面在C語言中不可替代的作用是什麼？ 簡單地抽象乙個類的共同特徵？

我嘗試了這個例子，刪除了類 a：icloneable，它仍然是可能的。 那有什麼用呢？ 我的結論是，使用該介面有兩個原因：

1：你自己設計的原因，有了規範，別人更容易理解你的系統是如何與你的介面一起工作的。

2：如果其他人設計了乙個介面，例如icompare）;由於別人的引數是乙個介面，如果你想使用這個函式，你的類也必須實現這個介面。 記得：

介面對應的是類，而不是方法，介面的物化就是類。 但是介面指定了類要實現的方法。

例如：public class valuecompare： icomparer}

該介面用於封裝，是最簡單的。

1. 介面的使用並不總是從設計的角度考慮。 介面與其他語法現象一樣，共同構成了整個語言系統。

2.介面的意義是抽象的、不受限制的，使相似的事物在同一層次上具有普遍性和可替代性。

3、關於解耦，不是介面可以解耦，而是抽象的介面可以解耦，介面只是乙個手段，如果兩者必然相關，那麼就不會有完全的解耦，只有耦合和轉移。

在進行分層開發時，通常使用底層通告介面供上層呼叫。

介面是一種約定俗成，就像大家只按照指定的約定做事一樣，但是對於這個規定，怎麼做，可以有不同的方式，這是先定義介面再實現的方式，不需要等到實現完成之後才能暴露， 介面定義好後，一旦發布，最好不要修改，否則會導致整合類被修改。

例如，假設您有乙個想要支援硬體裝置的專案。 在結構設計中，這部分的實現很可能會獨立實現（可能。

它由您的開發團隊完成，也可能外包）。此時，可以開發乙個介面。 客戶端和伺服器端都根據此定義進行開發。 沒關係。

保證雙方將來可以合作。 這就像生產螺釘和螺母一樣。

有時介面也可以在版權保護中起到一定的作用。 假設您製作了遠端處理服務。 您需要將存根發布到客戶端。 如果客戶。

結尾是由第三方編寫的。 您可能不想在沒有實現部分版本的情況下出去。 此時，您可以發布藉口定義。

通常，對服務的更改是通過新增到現有介面而不是直接修改來進行的。 為了便於管理。 這通常是在商業上完成的，您當然可以依賴版本。

控制，但沒有人這樣做。 如果改變現有介面，遇到更嚴重的糾紛，陷入糾紛，就很難掌握主動權。

沒有找到合適的重寫方法。

沒有找到合適的重寫方法。

很簡單，我不會告訴你到底出了什麼問題，但如果你告訴你為什麼錯了，你可以自己改變它，給人留下更深刻的印象。

首先，您必須了解重寫的概念。

下面是乙個示例。 你看，為什麼這句話不說，我沒有找到合適的方式來重寫它，當你點選它時，vs會給你乙個聰明的提示，告訴你到底應該寫什麼。

無論是 int、string 還是什麼都沒有，你都將學習這種方法。

沒有找到合適的重寫方法。

以這個為例。

當你寫這篇文章時，vs 絕對是乙個聰明的提示。

告訴你裡面能寫什麼，但一定不能說可以是空的，你是空的，所以我沒有找到合適的方法重寫它。

在以下情況下使用該介面：

1.當有一組可以呼叫的相關方法時。

2.當乙個類只需要乙個方法的單個實現時。

3.當使用介面的類想要將該介面強制轉換為其他介面或類型別時。

在不使用委託的情況下使用單個方法介面的乙個很好的示例是 icomparable<（of <（t>）） 的 icomparable 或泛型版本> icomparable 宣告 compareto 方法，該方法返回乙個整數，指定小於、等於或大於的相同型別的兩個物件之間的關係。 iComparable 可以用作排序演算法的基礎。

雖然使用委託比較方法作為排序演算法的基礎是有效的，但並不理想。 由於比較功能是乙個類，並且比較演算法在執行時不會更改，因此單方法介面是理想的選擇。

協議。 減少耦合。 你問這個問題，答案無處不在。 這就是我要說的。 看看樓下怎麼說。