理論概述

• cluelessness（無(wú)緒）

軟件開發(fā)并不需要了解每一個(gè)API背后的實(shí)現(xiàn)原理，只要知道它是怎么用的就可以了。這是大型軟件協(xié)作開發(fā)的理論基礎(chǔ)。

• API的范圍

API不僅僅是接口，類，方法，API可以是程序中任意暴露給使用者的事物。可以是文件結(jié)構(gòu)，也可以是通信協(xié)議，還可以是模塊組件。

• 一個(gè)好的API應(yīng)該有的特性

1）可理解性；API是程序員之間的溝通方式，容易看懂使用是最重要的。
2）一致性；同一類API風(fēng)格一致降低學(xué)習(xí)成本，不同版本的API功能要一致。
3）可見性；統(tǒng)一醒目的入口介紹API，最好有demo。
4）簡(jiǎn)單；給API分門別類，互不相關(guān)的API不要雜糅在一起。
5）向后兼容；新版盡可能不要修改或刪除API的定義，也不要調(diào)整API的結(jié)構(gòu)。

只公開必要的

• 工廠方法優(yōu)于構(gòu)造函數(shù)的原因

1）可以構(gòu)造子類對(duì)象返回，調(diào)用方無(wú)需關(guān)注子類類型。
2）可以返回緩存單例，而并不是每次都new一個(gè)新對(duì)象。
3）返回值可以是定義為帶泛型的，構(gòu)造函數(shù)不支持。
4）可以在對(duì)象構(gòu)造前后做一些額外的事情。

• Java實(shí)現(xiàn)友元訪問(wèn)

1）Java原生只有public, protected, private, default四種訪問(wèn)級(jí)別，沒(méi)有提供友元關(guān)鍵字來(lái)實(shí)現(xiàn)友元訪問(wèn)。
2）default訪問(wèn)級(jí)別為包級(jí)別訪問(wèn)，即同一個(gè)package之下的類能夠互相訪問(wèn)。
3）如果要對(duì)類 C 實(shí)現(xiàn)友元訪問(wèn)，則 C 的所有方法都應(yīng)該設(shè)置為default級(jí)別；然后在同一個(gè)包內(nèi)定義一個(gè) C 的代理類 DelegateC ，由 DelegateC 對(duì)外提供public的接口，內(nèi)部調(diào)用 C 的方法來(lái)執(zhí)行邏輯。

模塊化架構(gòu)

• 采用模塊化架構(gòu)的原因

1）模塊化架構(gòu)是把復(fù)雜的單個(gè)應(yīng)用程序分拆成互相之間有清晰依賴關(guān)系的模塊，有利于軟件的進(jìn)化。
2）即使一個(gè)最簡(jiǎn)單的WEB應(yīng)用，也可以拆成dal, biz, web三個(gè)模塊，dal負(fù)責(zé)數(shù)據(jù)訪問(wèn)，biz負(fù)責(zé)業(yè)務(wù)邏輯，web負(fù)責(zé)請(qǐng)求控制與顯示。每個(gè)模塊都只公開必要的接口給外部模塊訪問(wèn)，這樣即使一個(gè)模塊內(nèi)部爛到骨子里，也不會(huì)腐蝕另一個(gè)干凈的模塊。

• 服務(wù)注冊(cè)發(fā)現(xiàn)的幾個(gè)方案

1）使用一個(gè)啟動(dòng)類，將被用到的模塊中的服務(wù)類，實(shí)例化對(duì)象注冊(cè)進(jìn)來(lái)。缺點(diǎn)：硬編碼方式不容易擴(kuò)展。
2）依賴注入，采用配置文件或者注解的方式裝配服務(wù)對(duì)象，如spring。缺點(diǎn)：除了需要用戶主動(dòng)裝配外，基本完美。
3）Java標(biāo)準(zhǔn)的ServiceLoader機(jī)制。缺點(diǎn)：未提供完整的對(duì)象生命周期管理。
4) Netbeans 的Lookup。本質(zhì)上是增強(qiáng)版的ServiceLoader，比如監(jiān)聽功能。

API 和 SPI

• 主要區(qū)別

1）API主要是給外部客戶調(diào)用的，一般會(huì)以代理的方式實(shí)現(xiàn)；SPI主要是給服務(wù)提供者擴(kuò)展的，一般會(huì)以繼承的方式實(shí)現(xiàn)。
2）新版本演進(jìn)時(shí)，給API增加方法并不影響原有功能，而刪減會(huì)；給SPI刪減方法并不影響服務(wù)，而增加會(huì)；

• 最佳實(shí)踐

1）不管是API還是SPI，最好區(qū)分核心還是非核心，方便90%的用戶能夠不受干擾，快速找到自己想要的。
2）設(shè)計(jì)時(shí)，識(shí)別API和SPI，放在不同的包內(nèi)，區(qū)分對(duì)待更容易新版本的演進(jìn)。

測(cè)試先行

• 為每一個(gè)API提供單元測(cè)試

1）用戶使用API的方式千奇百怪，只有對(duì)每一個(gè)API提供單元測(cè)試，才能放心地變更API的內(nèi)部實(shí)現(xiàn)。
2）單元測(cè)試不同于集成測(cè)試，如果遇到需要調(diào)用外部接口的情況，能mock盡量mock。

• 測(cè)試用例的演進(jìn)

1）每一次的bug修復(fù)，都先補(bǔ)相應(yīng)的測(cè)試用例來(lái)重現(xiàn)，再修復(fù)后驗(yàn)證。

API設(shè)計(jì)

• 極端的建議有害無(wú)益，做好平衡

1）API必須是漂亮的；首先得是正確的。
2）API必須是正確的：只需要在可期的時(shí)間規(guī)模內(nèi)是正確的即可。
3）API必須是簡(jiǎn)單的；不能以犧牲功能為代價(jià)。
4）API必須是高性能的；優(yōu)化性能萬(wàn)惡之源，跟其他所有特性相違背。
5）API必須是完全兼容的；評(píng)估完全兼容的代價(jià)，平衡資源。

• API的開發(fā)和維護(hù)

1）API第一版本發(fā)布是最需要謹(jǐn)慎的，一旦發(fā)布即做出了向后兼容的承諾；
2）API的維護(hù)成本高昂，每一次升級(jí)都盡可能小心。