「編程到接口」是什麼意思？

我已經看過幾回這個問題了，我不清楚它是什麼意思。 您什麼時候以及爲何要這樣作？

我知道接口的做用，可是我對此不清楚，這使我以爲我錯過了正確使用它們的機會。

若是要這樣作，是否只是這樣：

IInterface classRef = new ObjectWhatever()

您可使用實現IInterface任何類嗎？ 您何時須要這樣作？ 我惟一能想到的是，若是您有一個方法，而且不肯定要實現IInterface對象，則不肯定該對象將被傳遞。 我不認爲您須要多久這樣作一次。

另外，您如何編寫一個接受實現接口的對象的方法？ 那可能嗎？

---

#1樓

接口的編程與Java或.NET中的抽象接口絕對無關。 它甚至不是OOP概念。

這意味着不要搞亂對象或數據結構的內部。 使用抽象程序接口或API與您的數據進行交互。 在Java或C＃中，這意味着使用公共屬性和方法而不是原始字段訪問。 對於C，這意味着使用函數而不是原始指針。

編輯：對於數據庫，這意味着使用視圖和存儲過程，而不是直接表訪問。

---

#2樓

C ++解釋。

將接口視爲類的公共方法。

而後，您能夠建立一個「依賴」這些公共方法的模板，以執行其本身的功能（它使在類的公共接口中定義的函數調用）。 能夠說，此模板是一個容器，例如Vector類，而且它依賴的接口是搜索算法。

定義函數/接口Vector進行調用的任何算法類都將知足「合同」（如原始答覆中所解釋的）。 這些算法甚至沒必要是相同的基類。 惟一的要求是在算法中定義Vector依賴的函數/方法（接口）。

全部這些的目的是，您能夠提供任何不一樣的搜索算法/類，只要它提供了Vector依賴的接口（氣泡搜索，順序搜索，快速搜索）便可。

您可能還須要設計其餘容器（列表，隊列），這些容器能夠經過使它們知足您的搜索算法所依賴的接口/合同來利用與Vector相同的搜索算法。

這樣能夠節省時間（OOP原則「代碼重用」），由於您可以針對建立的每一個新對象編寫一次而不是一次又一次地編寫算法，而不會因過分使用繼承樹而使問題複雜化。

至於「錯過」事情如何運做； 大型應用程序（至少在C ++中），由於這是大多數標準TEMPLATE庫框架的工做方式。

固然，當使用繼承和抽象類時，對接口進行編程的方法會發生變化。 可是原理是同樣的，您的公共函數/方法是您的類接口。

這是一個巨大的主題，也是「設計模式」的基石原則之一。

---

#3樓

那裏有不少解釋，但要使其更加簡單。 以List爲例。 可使用如下方式實現列表：

1. 內部數組
2. 鏈表
3. 其餘實施

經過構建接口，說一個List 。 您只須要編碼List的定義或List實際上的含義。

您能夠在內部使用任何類型的實現，例如array實現。 可是假設您出於某種緣由（例如錯誤或性能）而但願更改實現。 而後，您只須要將聲明List<String> ls = new ArrayList<String>()更改成List<String> ls = new LinkedList<String>() 。

代碼中沒有其餘地方，您是否須要更改其餘任何內容？ 由於其餘全部內容都基於List的定義。

---

#4樓

問：-...「您能使用任何實現接口的類嗎？」
答：是的。

問：-...「您何時須要這樣作？」
答：-每次須要一個實現接口的類。

注意： 咱們沒法實例化類未實現的接口 -True。

• 爲何？
• 由於該接口僅具備方法原型，而沒有定義（僅是函數名稱，而不是其邏輯）

AnIntf anInst = new Aclass();
// 僅當 Aclass實現AnIntf​​時，咱們才能這樣作。
// anInst將具備Aclass引用。

---

注意： 如今咱們能夠理解，若是Bclass和Cclass實現相同的Dintf，會發生什麼。

Dintf bInst = new Bclass();  
// now we could call all Dintf functions implemented (defined) in Bclass.

Dintf cInst = new Cclass();  
// now we could call all Dintf functions implemented (defined) in Cclass.

咱們所擁有的：相同的接口原型（接口中的函數名稱），並調用不一樣的實現。

參考書目： 原型-維基百科

---

#5樓

短篇小說：要求郵遞員回家後回家，並接收包含其上寫有地址的封面（信件，文件，支票，禮品卡，申請書，情書）。

假設沒有掩護，請郵遞員回家後收拾全部東西並交付給其餘人，郵遞員會感到困惑。

因此最好用封面包好（在咱們的故事中是界面），而後他會作得很好。

如今，郵遞員的工做是僅接收和交付封面（他不會打擾封面中的內容）。

建立不是實際類型的interface類型，而是使用實際類型實現它。

建立接口意味着您的組件能夠輕鬆適應其他代碼

我舉一個例子。

您具備以下的AirPlane界面。

interface Airplane{
    parkPlane();
    servicePlane();
}

假設您的飛機控制器類中有一些方法，例如

parkPlane(Airplane plane)

和

servicePlane(Airplane plane)

在您的程序中實現。 它不會破壞您的代碼。 個人意思是，只要接受像AirPlane這樣的參數，就不須要更改。

由於它將接受任何飛機，而無論實際的類型， flyer ，高highflyr ， fighter等。

另外，在集合中：

List<Airplane> plane; //將搭乘您的全部飛機。

如下示例將清除您的理解。

---

你有一架實施它的戰鬥機，因此

public class Fighter implements Airplane {

    public void  parkPlane(){
        // Specific implementations for fighter plane to park
    }
    public void  servicePlane(){
        // Specific implementatoins for fighter plane to service.
    }
}

HighFlyer和其餘事件也是如此：

public class HighFlyer implements Airplane {

    public void  parkPlane(){
        // Specific implementations for HighFlyer plane to park
    }

    public void  servicePlane(){
        // specific implementatoins for HighFlyer plane to service.
    }
}

如今考慮使用AirPlane幾回您的控制器類，

假設您的Controller類是ControlPlane，以下所示，

public Class ControlPlane{ 
 AirPlane plane;
 // so much method with AirPlane reference are used here...
}

神奇之處在於，您可使新的AirPlane類型實例達到所需的數量，而且無需更改ControlPlane類的代碼。

您能夠添加一個實例...

JumboJetPlane // implementing AirPlane interface.
AirBus        // implementing AirPlane interface.

您也能夠刪除之前建立的類型的實例。