讓定義的介面可讀性更強
做程式開發一段時間之後，會慢慢意識到面向過程程式設計與物件導向程式設計之間的差異。兩種方式，都可以解決具體的問題，只是，面向過程程式設計無法應對複雜而多變的需求，隨著專案不停迭代，複雜度上公升，你會逐漸意識到它的短板以及災難性的維護成本，這還只是其一；第二個會遇到的難題，就是用面向過程的編碼方式，無法將簡單的小功能堆砌為複雜而靈活的大功能，太多不必要的**裸露出來，分散了你的注意力，無法將心思放在實現邏輯之上。如果不鍛鍊你的物件導向程式設計思維，你無法提高你的編碼技術，猶如武俠中練武之人，不注重內功心法，學再多的武功秘籍，也無法將武技發揮到極致，更無法持久的輸出戰力。在物件導向程式設計中，有很多規定來約束物件的建立，以及介面的使用。約束物件建立方面，有黎克特制代換原則（遵循黎克特制代換原則可以讓你將多型發揮到極致）以及開閉原則（對修改關閉，對擴充套件開放）；介面使用方面，有依賴倒轉原則（針對介面程式設計）以及介面隔離原則（保持介面職能單一）。
這篇文章中，本人分享一些自己的心得體會，強調定義介面的重要性，側重點在於如何讓介面見名知意，是如何定義介面的乙個片段而已，並不囊括全部如何定義介面全部的內容。直接切入正題。
只處理抽象物件的情形
這個抽象基類定義了一些基本的屬性值，強調的是取值的特性，行為特徵少（方法很少或者沒有方法）。而某些取值的差異化，是通過派生子類的方式過載對應屬性的getter，setter方法而已，比方說，我們需要在子類中對取name值加乙個字首，那麼，子類過載了其name屬性的getter方法即可，介面的定義就用抽象基類輸入引數為主：
只處理抽象介面的情形
這是乙個協議，我們注重的是協議中通用的行為，任何物件，只要實現了這個行為，都可以作為介面的引數，那麼，我們需要用下面的定義方式，來強調，你需要乙個實現了此協議的物件：
對抽象物件與抽象介面都有要求的情形
如下所示，我們可以將抽象的介面附著在抽象的基類上，強調了這個抽象基類需要實現這些抽象的行為才能達到客戶端的需要：
為了達到強調的效果，介面需要這麼定義：
* 以上三個都是為了強調介面的可讀性，讓人知道你想表達什麼，以及讓使用者如何操作
萬能適配的情形
你很有自信適配所有型別的資料，你會這麼寫：
這麼寫其實並不好，因為沒人知道id型別的model到底是做什麼用的，因為你沒有對model進行任何行為的規範（沒有指明model的型別，或者model需要遵守的協議），只有當你的介面適配了所有的物件，或者內部寫好了介面卡，才能這麼做，即使是這樣，也會讓可讀性變差。
以上講的幾點，都是基於抽象基類與抽象行為彼此分離的這種設定，抽象基類本身也會帶有方法，只有在某些方法需要子類過載的時候，我們才會將其提取出來放在抽象行為（協議）當中，我們做這些事情的目的，核心思想都是在增加程式可讀性以及可維護性。還有，**是寫給別人看的。
談程式設計的可讀性藝術
程式的可讀性，簡而言之，就是設計和編寫的 可以讓更多的人讀懂 傳承與復用。既然如此，那麼如何實現程式設計的可讀性藝術，值得設計和編寫程式者思考與實踐了。通過閱讀一些經典書籍和 加上自己的親身實踐與體會。總體感覺，可以從以下四個方面來提公升程式設計的可讀性。首先，通過反覆地實踐，培養成程式設計與 編寫...
（翻譯）新式營養標籤的可讀性
營養標籤的樣式幾十年來保持不變，但美國食品藥物管理局準備重新設計營養標籤的樣式。對比新舊樣式，可以看出新的設計支援快速瀏覽及易於檢視的原因。增加文字大小，提高視敏度 請注意，新版營養標籤中，標題 卡路里及份量屬於首要資訊，他們的字型最大。增加一段文字的字型大小，其周圍文字尺寸不變，就提高了變大文字的...
如何讓你的文章更有可讀性，讓大家分享點讚收藏？
優化標題只是為了讓讀者在資訊流中快速注意到你，而展示你真正實力的則是文章內容本身。我們經常在部落格上看到一些技術文章，通篇都是大段大段程式碼，截個圖出個結果，就完事了。大家都是程式設計師，固然覺得程式碼是重要載體，但文章畢竟是文章，可讀性還是很重要的。如果我們決定寫一篇可以拿得出手的技術文章，給大家...