一、“接口”初步：

從OOP設計角度來分析，“接口”是一個很特殊的“類”，特殊之處在于：

1）不能為接口中定義的方法添加關鍵字（只允許是public）。

2）可以定義事件/方法/屬性，但都無法實現（只能讓實現類去實現）。

以上這些限制了接口的應用范圍——意味著接口只是作為一個對類的契約而存在，談不上“代碼復用”（因為接口自身不能定義方法，自然實現類無法調用它們，也就不構成重載/重寫的概念了），也根本不存在“繼承”的概念。因此“接口”的關鍵字是Implement而不是Inherit（在C#中則都是英文狀態的冒號）。

由接口自身的定義，我們聯想到最簡單的接口應用就是強制某個類必須具備某種方法，譬如說我要設計一個圍棋程序，其中的“棋子”如果是一個類，那么星羅密布的圍棋子其實都是自身的拷貝和翻版，因此我可以實現NET自帶的IClonable類；又如NET自帶的數據庫類中由于需要消耗大量內存和磁盤開銷，因此及時釋放內存很有必要；此時我們可以實現IDispose接口來強制讓這個類帶有Dispose方法，用于銷毀內部消耗大量資源的托管和非托管組件和實例等東西。

其次，實現了一個特定接口的類可以通過接口來調用。這就意味著對于客戶端而言，無需知道接口內具體方法是如何實現的，只要知道能夠實現這個效果是哪個類，直接用接口引用這個類的實體就可以了。這就是我們所謂的“面向接口編程”。NET一些特定場景下大量使用到接口，譬如最典型的泛型List中Sort方法就是傳入一個實現了IComparer<T>的接口——只要你把實現了這個接口的實例當成參數傳入到此方法中，則Sort內部自動調用你的方法排序，相對于NET類庫而言方法是黑箱的：它只需要結果，根本不關心過程。這種“屏蔽實現端，讓客戶只知道該知道的東西的”的設計理念還廣泛地應用于各類OOP設計模式中——比如工廠模式，適配器模式等。

讓子類去實現具體方法并非“接口”之專利，“抽象類”的abstract方法也是延時實現。那么它們有何區別呢？

二、“接口”VS“抽象類”：

這個題目簡直每次面試都被問及，但要真正說清楚它們的區別還真的非常不容易！前面已經說過——抽象類是類的抽象表述（不可實例化，一般具備一個或多個abstract方法讓子類去實現），因此抽象類主要的作用在于盡可能提高“代碼復用”（包括方法繼承以及方法重載/重寫），而且一個抽象類往往衍生出多個具備相似功能的子類，因而抽象類是衍生其它一系列類的通用模板。

相比較而言接口非常單純，“城府”遠沒有“抽象類”那么“深”：簡而言之，接口作用只是讓某個類擁有某個方法，這個方法是對外公開暴露的，也就是可以為其它擁有該接口的類隨意調用，可以使得兩個毫不相干的類在不引用的情況下發生特殊的關系——最經典的例子莫過于“設計模式”中的“觀察者模式”，微軟由此基礎上發展出“事件”來取代這種模式，但是它的的確確是“事件”的開山鼻祖。

同時，抽象類衍生出的子類必然具備抽象類允許繼承的全部方法（即便是重寫！），但是有時并不都是需要這些方法時（比如通過“鴨子工廠”介紹策略模式就是一個典型），接口往往可以把變化的方法和不變的隔離，達到動態的效果。

談到策略模式，其實“策略模式”的本質是通過一個基本的策略工具衍生出若干個相關的策略算法，然后在其它類中引用“策略工具”，由不同實現該工具的“策略算法”決定如何進行策略的一種設計模式。“策略工具”如果說只是一個單純的“算法”，那么完全可以使用接口；如果是一個復雜的，乃至這個“策略工具”可以派生出大量類似的“策略算法”的，優先考慮的是抽象類而不是接口。

轉載于:https://www.cnblogs.com/ServiceboyNew/archive/2012/11/19/2775779.html

總結

以上是生活随笔為你收集整理的OOP设计思考——何时使用接口？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。