前言

代碼每個人都會寫箭跳。但是，能把代碼寫的優(yōu)美潭千，把結(jié)構(gòu)設(shè)計的足夠靈活谱姓，并且讓人贊嘆的人卻很少。尤其在中國這樣的大環(huán)境里刨晴。大部分人都是為了生活而奔波屉来。編程只不過是一份工作而已。所以狈癞，我想茄靠，你肯定也曾經(jīng)像我一樣，看到很多想罵娘的代碼蝶桶。這些代碼通常被稱之為面條代碼慨绳，所謂的面條代碼，就是寫的像長媽媽的裹腳布一樣真竖，又臭又長脐雪。讓人理不清，理還亂恢共，是離愁战秋，別是一番滋味在心頭。

筆者工作只不過短短幾年讨韭，但從來不敢輕視編程脂信，一直視編程為一件非常神圣的事情癣蟋。從一開始，我就嚴(yán)格按照代碼格式去構(gòu)建我的代碼狰闪，最初的時候梢薪，拿開發(fā)工具格式化基本都沒有變化。現(xiàn)在想想尝哆，正是源于當(dāng)初對待編程戰(zhàn)戰(zhàn)兢兢，如履薄冰一般甜攀，才有了現(xiàn)在非常漂亮的代碼習(xí)慣秋泄。在筆者工作的這幾年里，每天和Code約會的時間最長规阀，先后掌握了Java,C++,OC,Swift等語言恒序，工作中接觸最多的還是Java語言，但從其他語言中我也吸收了很多營養(yǎng)谁撼。鑒于筆者這些年的經(jīng)驗歧胁，希望寫一篇文章講一講接口的設(shè)計，筆者水平有限厉碟，文章只當(dāng)是拋磚引玉喊巍，如果有更好的設(shè)計，請在文章下方留言告訴我箍鼓。

避免過度封裝

這是我想說的第一點(diǎn)崭参，很多人喜歡這樣封裝，把接口局限在僅僅解決一個特定的問題上面款咖，失去了代碼的靈活性何暮。而且，也容易出現(xiàn)面條代碼铐殃，讓人不知所云海洼。筆者的工作中已經(jīng)遇到了很多這樣的問題，一個接口被寫的僅僅用于解決當(dāng)前問題富腊，當(dāng)筆者試圖增加其擴(kuò)展性時坏逢，發(fā)現(xiàn)為時已晚。任我移花接木蟹肘，甚至是斗轉(zhuǎn)星移都無法使其逆轉(zhuǎn)词疼。遇到這種情況，筆者常常是另辟蹊徑帘腹，將垃圾接口代碼標(biāo)注為@Deprecated,重新寫一套接口贰盗。為了防止過度封裝，在設(shè)計接口的時候阳欲，我們應(yīng)該考慮以下幾個問題：

• 我們需要解決什么問題
• 問題的核心是什么
• 應(yīng)該怎樣設(shè)計舵盈，可以方便客戶程序員擴(kuò)展

第一點(diǎn)陋率，我們需要找出我們將要解決的問題，這個看似容易的工作秽晚，其實(shí)并不容易瓦糟，很多人即便遇到了問題，依然不知道自己到底要解決什么問題赴蝇。只是使用一些面條代碼菩浙，飲鴆止渴。最終句伶，害人害己劲蜻。

第二點(diǎn)，我們需要找出問題的核心考余，一定要記住先嬉，是找出問題的核心，而不是直接解決問題的方法楚堤。如果你只是找出直接解決問題的方法疫蔓。那么，這個代碼一定是不具有任何擴(kuò)展性身冬，也不能稱之為接口衅胀。我們只能認(rèn)為，他寫了一堆代碼酥筝，解決了一個問題拗小。

第三點(diǎn)，一定要充分考慮接口的可擴(kuò)展性樱哼，這就要求在做接口設(shè)計的時候哀九，要站在客戶程序員的角度去想問題。他要怎樣使用我的代碼搅幅，他會如何擴(kuò)展我的代碼阅束。所以，記得要該放手時就放手茄唐，不要把過多的工作寫在你的接口里面息裸，而應(yīng)該把更多的主動權(quán)交給客戶程序員。

見名知意

接口中沪编，方法的設(shè)計一定要力求簡潔呼盆，而且要見名知意。如果筆者的同事有在注意筆者編碼的話蚁廓，一定會發(fā)現(xiàn)访圃，筆者在設(shè)計接口的時候，花在名稱的定義上時間是很長的相嵌。
這里舉一個簡單的例子腿时，在Java語言中况脆，單例的方法名幾乎已經(jīng)是習(xí)慣了，叫做getInstance()批糟「窳耍可是，仔細(xì)想一想徽鼎，getInstance()真的可以表達(dá)單例的意思嗎盛末？答案是：完全不能。getInstance()更像是工廠方法的命名否淤。而筆者認(rèn)為OC語言命名單例的方法就高明了許多满败，iOS程序員一定熟悉sharedInstance()方法，共享的單例叹括。一下子就將單例的意思表達(dá)的簡明扼要，如流水般清晰自然宵荒。

這只是一個簡單的例子汁雷，筆者希望告訴大家，在設(shè)計的接口的時候报咳，接口的名稱一定不能偷懶侠讯，拿發(fā)起POST請求的方法名命名。如果你稱之為sendReq()暑刃。那么厢漩，請問客戶程序員怎么知道這是要發(fā)起GET請求還是POST請求？客戶程序員在使用這個方法的時候無疑要點(diǎn)擊進(jìn)入源碼查看岩臣，大大增加了開發(fā)成本溜嗜。
因此，筆者認(rèn)為架谎，一個好的的接口方法名炸宵，是接口設(shè)計中成功的一半。而要想讓接口設(shè)計的優(yōu)雅谷扣，自然土全，請繼續(xù)關(guān)注下面的文章。

僅把必要的工作交給客戶程序員

什么叫必要会涎，這里可以理解為裹匙，當(dāng)前無法估計的操作。比如轉(zhuǎn)換到具體的數(shù)據(jù)類型末秃，而具體是什么類型概页，接口設(shè)計者是未知的。那么這個操作就可以交給客戶程序員练慕。同時绰沥，要注意的是篱蝇，不要給客戶程序員過多的工作。過多的工作設(shè)計就意味著這個接口的設(shè)計是完全失敗的徽曲。同時零截，也不符合接口的概念。充其量也只能稱之為解決一個問題秃臣。所以涧衙，設(shè)計的時候要記得盡可能簡化客戶程序員邏輯，使接口設(shè)計能夠看起來簡潔奥此、漂亮弧哎，而不至于被接口的復(fù)雜性所嚇倒。

充分保證程序的可擴(kuò)展性

其實(shí)做到上面幾點(diǎn)稚虎，程序的可擴(kuò)展性基本已經(jīng)有了保證撤嫩，但還有一些工作必不可少。在設(shè)計接口的時候蠢终，要充分考慮是否需要被重寫序攘，如果需要被重寫，考慮標(biāo)注protected寻拂。否則程奠，標(biāo)注private。對于不明確的方法祭钉，請慎重考慮瞄沙，被重寫的可能性。如果幾乎為0慌核，則不考慮其被重寫距境。另外，在保證充分可擴(kuò)展性的前提下垮卓，也要保證數(shù)據(jù)的完整性肮疗，不可因為客戶程序的錯誤訪問，導(dǎo)致接口設(shè)計出現(xiàn)異常扒接。所以伪货，適度很重要，不要因為擴(kuò)展性而丟失了數(shù)據(jù)的完整性钾怔。

簡潔

接口的設(shè)計一定要充分簡潔碱呼。這很重要，見過很多程序員宗侦，為了保證接口的充分可用性愚臀，設(shè)計了一堆參數(shù)。但其實(shí)矾利，大部分情況下客戶程序員只需要一兩個參數(shù)即可姑裂。這樣的設(shè)計就違背了接口設(shè)計的簡潔原則馋袜。會讓很多客戶程序員望而生畏，放棄對該接口的使用舶斧⌒辣睿或者進(jìn)行二次封裝。所以茴厉，簡潔設(shè)計是接口設(shè)計的一個重要原則泽台。可以在接口的內(nèi)部實(shí)現(xiàn)中矾缓，使用復(fù)雜冗余的參數(shù)怀酷，而在暴露給客戶程序員的接口中，一定要盡可能簡潔嗜闻。

百分比原則

在接口的設(shè)計中蜕依，難免要設(shè)置一些默認(rèn)操作，在設(shè)計默認(rèn)操作的時候琉雳，一定要充分考慮用戶的使用習(xí)慣样眠。比如接口的操作有兩種，要充分對比這兩種操作頻繁度咐吼。這里假設(shè)操作有A，B兩種商佑，如果A操作更為頻繁锯茄，則應(yīng)該將A操作設(shè)為默認(rèn)，反之茶没，則為B肌幽。這里可以認(rèn)為A操作的百分比超過了50%，故取其作為默認(rèn)值抓半，筆者將其稱為百分比原則喂急。即根據(jù)操作的頻繁度依次排名，取百分比最大的操作為默認(rèn)值笛求。

文檔表述要清晰

良好的接口設(shè)計廊移，離不開清晰的接口文檔表述。文檔表述一定要足夠詳細(xì)探入，使客戶程序員充分知道該接口的用法以及需要注意的問題狡孔。這一點(diǎn)是很多接口設(shè)計者容易忽略的。但這一點(diǎn)的重要性蜂嗽，筆者認(rèn)為甚至超越了上面所有點(diǎn)的總和苗膝。

總結(jié)

接口的設(shè)計是實(shí)際開發(fā)中必不可少的一環(huán)，也是最重要的一環(huán)植旧。良好的接口設(shè)計能夠起到事半功倍的效果辱揭，而雜亂無章的接口設(shè)計有時甚至?xí)斐蔁o法挽回的損失离唐。因此，在設(shè)計接口的時候问窃，請慎重考慮上面的設(shè)計原則亥鬓。有一句古話告訴我們，磨刀不誤砍柴工泡躯，說的就是這個道理贮竟！