編寫代碼的「八榮八恥」- 以用戶易用爲榮，以複雜歧義爲恥

概述

本文是繼《編寫代碼的「八榮八恥」(上篇)》和《編寫代碼的「八榮八恥」-以開關上線爲榮，以自信編碼爲恥 》以後，編寫代碼的「八榮八恥」系列的第三篇。

本篇總體框架仍是採用經典的問題分析三步曲：what、why、how。

 

WHAT

編寫代碼的「八榮八恥」

1. 產品命名：以簡單有趣爲榮，以平庸難記爲恥。

2. 單個方法：以短小精悍爲榮，以冗長費神爲恥。

3. 代碼維護：以持續重構爲榮，以停滯不前爲恥。

4. 編程思想：以面向對象爲榮，以面向過程爲恥。

5. 程序設計：以開關上線爲榮，以自信編碼爲恥。

6. 接口定義：以用戶易用爲榮，以複雜歧義爲恥。

7. 斷言分支：以實時報警爲榮，以忽略分支爲恥。

8. 報警策略：以定時調整爲榮，以放棄維護爲恥。

 

WHY

面向對象的設計中，之因此要抽象成接口，而不直接面向實現類。主要是基於「抽象比細節更長久」的理論基礎，實現類可更改可替換。

 

調用方不須要關心接口怎麼實現，只須要知道接口作什麼和怎麼用便可。這也註定了接口設計的兩個基本指標：易懂和易用。

 

HOW

這裏主要針對平時工做中看到的同窗常常犯的三個誤區作建議。

1. 以一應俱全爲恥

2. 以需傳默認爲恥

3. 以按業務定義爲榮，以按技術定義爲恥。

來看一下出現這個三個誤區的影響三葉草：

 

從圖中能夠看出，出現這三個誤區，最終會產出難懂又難用的爛接口。下面針對這三個方面給出具體的例子。

 

以一應俱全爲恥

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工具讓客戶端可方便的合成。不要把這些任務交給調用方本身去完成。

上面一堆代碼能夠經過「策略下沉」將其抽象爲一種策略，打個比方定義爲：通用宿主機正常狀態選項。把這個選項作成封裝暴露出去，不是直接讓調用方來拼這個入參。

 

總結

少便是多

 

溫故知新

JAVA日誌的前世此生

從技術渣到被要求改行到硅谷程序媛

跑題時間：接下來5個月的計劃

簡明日誌規範