概述 本文是繼《編寫代碼的「八榮八恥」(上篇)》和《編寫代碼的「八榮八恥」-以開關上線為榮，以自信編碼為恥 》之後，編寫代碼的「八榮八恥」系列的第三篇。 本篇整體框架還是採用經典的問題分析三步曲：what、why、how。 WHAT 編寫代碼的「八榮八恥」 1. 產品命名：以簡單有趣為榮，以平庸難記 ...
概述
本文是繼《編寫代碼的「八榮八恥」(上篇)》和《編寫代碼的「八榮八恥」-以開關上線為榮，以自信編碼為恥 》之後，編寫代碼的「八榮八恥」系列的第三篇。
本篇整體框架還是採用經典的問題分析三步曲：what、why、how。
WHAT
編寫代碼的「八榮八恥」
1. 產品命名：以簡單有趣為榮，以平庸難記為恥。
2. 單個方法：以短小精悍為榮，以冗長費神為恥。
3. 代碼維護：以持續重構為榮，以停滯不前為恥。
4. 編程思想：以面向對象為榮，以面向過程為恥。
5. 程式設計：以開關上線為榮，以自信編碼為恥。
6. 介面定義：以用戶易用為榮，以複雜歧義為恥。
7. 斷言分支：以實時報警為榮，以忽略分支為恥。
8. 報警策略：以定時調整為榮，以放棄維護為恥。
WHY
面向對象的設計中，之所以要抽象成介面，而不直接面向實現類。主要是基於「抽象比細節更長久」的理論基礎，實現類可更改可替換。
調用方不需要關心介面怎麼實現，只需要知道介面做什麼和怎麼用即可。這也註定了介面設計的兩個基本指標：易懂和易用。
HOW
這裡主要針對平時工作中看到的同學經常犯的三個誤區做建議。
-
以包羅萬象為恥
-
以需傳預設為恥
-
以按業務定義為榮，以按技術定義為恥。
來看一下出現這個三個誤區的影響三葉草：
從圖中可以看出，出現這三個誤區，最終會產出難懂又難用的爛介面。下麵針對這三個方面給出具體的例子。
以包羅萬象為恥
Elasticsearch(ES)很強大，支持很多複雜查詢。做了一個查詢系統，底層用了ES做存儲。提供介面給上層調用。如果直接把ES介面作為自己的業務介面給上層來調用，這會很強大，想查的東西一定可以查到。但是請回家路上小心點，很可能第二天就看不到你來上班了，因為被做上層的同事給打死了。
比較好的一個實踐是針對上層調用方的具體需求，產生出一個更加有針對性的介面。有很簡單的入參和出參。比如ES里存的是世界地圖。上層調用方是做定位的。他會輸入兩個參數：經度和緯度。他只需要返回一個信息：所在城市。那就自己封裝好給調用方提供一個根據經緯度查詢城市的介面就好了。
以需傳預設為恥
這個很好理解。下麵是java.lang.String類的構造方法。如果不提供只有char入參的，每次調用都需要填寫預設的new String('f',-1,2)，是不是很想砍人？
最悲催的是這種形式的調用：
Shit shit = crap.shit("shit",null,null,null,null,null,null);
數null數到頭暈。底層封裝一層撒。
以按業務定義為榮，以按技術定義為恥
其實靜兒在寫代碼的時候經常寫這樣一種實現：定義一個XXXBuilder，入參是一個XXXXOption類。這是一種常見的設計模式。將各種選項放到構造器里構造出真正需要的入參。然後再交給一個介面讓它去完成功能。構造入參代碼舉例如下：
是不是很頭大？作為基礎介面提供者，需要將這些複雜的技術邏輯封裝好成業務領域的介面。實在是邏輯複雜也要自己提供靜態的Builder工具讓客戶端可方便的合成。不要把這些任務交給調用方自己去完成。
上面一堆代碼可以通過「策略下沉」將其抽象為一種策略，打個比方定義為：通用宿主機正常狀態選項。把這個選項做成封裝暴露出去，不是直接讓調用方來拼這個入參。
總結
少即是多
溫故知新
