讓定義的介面可讀性更強
做程式開發一段時間之後，會慢慢意識到程式導向程式設計與物件導向程式設計之間的差異。兩種方式，都可以解決具體的問題，只是，程式導向程式設計無法應對複雜而多變的需求，隨著專案不停迭代，複雜度上升，你會逐漸意識到它的短板以及災難性的維護成本，這還只是其一；第二個會遇到的難題，就是用程式導向的編碼方式，無法將簡單的小功能堆砌為複雜而靈活的大功能，太多不必要的程式碼裸露出來，分散了你的注意力，無法將心思放在實現邏輯之上。如果不鍛鍊你的物件導向程式設計思維，你無法提高你的編碼技術，猶如武俠中練武之人，不注重內功心法，學再多的武功祕籍，也無法將武技發揮到極致，更無法持久的輸出戰力。在物件導向程式設計中，有很多規定來約束物件的建立，以及介面的使用。約束物件建立方面，有里氏代換原則（遵循里氏代換原則可以讓你將多型發揮到極致）以及開閉原則（對修改關閉，對擴充套件開放）；介面使用方面，有依賴倒轉原則（針對介面程式設計）以及介面隔離原則（保持介面職能單一）。
這篇文章中，本人分享一些自己的心得體會，強調定義介面的重要性，側重點在於如何讓介面見名知意，是如何定義介面的一個片段而已，並不囊括全部如何定義介面全部的內容。直接切入正題。
只處理抽象物件的情形
這個抽象基類定義了一些基本的屬性值，強調的是取值的特性，行為特徵少（方法很少或者沒有方法）。而某些取值的差異化，是通過派生子類的方式過載對應屬性的getter，setter方法而已，比方說，我們需要在子類中對取name值加一個字首，那麼，子類過載了其name屬性的getter方法即可，介面的定義就用抽象基類輸入引數為主：
只處理抽象介面的情形
這是一個協議，我們注重的是協議中通用的行為，任何物件，只要實現了這個行為，都可以作為介面的引數，那麼，我們需要用下面的定義方式，來強調，你需要一個實現了此協議的物件：
對抽象物件與抽象介面都有要求的情形
如下所示，我們可以將抽象的介面附著在抽象的基類上，強調了這個抽象基類需要實現這些抽象的行為才能達到客戶端的需要：
為了達到強調的效果，介面需要這麼定義：
* 以上三個都是為了強調介面的可讀性，讓人知道你想表達什麼，以及讓使用者如何操作
萬能適配的情形
你很有自信適配所有型別的資料，你會這麼寫：
這麼寫其實並不好，因為沒人知道id型別的model到底是做什麼用的，因為你沒有對model進行任何行為的規範（沒有指明model的型別，或者model需要遵守的協議），只有當你的介面適配了所有的物件，或者內部寫好了介面卡，才能這麼做，即使是這樣，也會讓可讀性變差。
以上講的幾點，都是基於抽象基類與抽象行為彼此分離的這種設定，抽象基類本身也會帶有方法，只有在某些方法需要子類過載的時候，我們才會將其提取出來放在抽象行為（協議）當中，我們做這些事情的目的，核心思想都是在增加程式可讀性以及可維護性。還有，程式碼是寫給別人看的。