這篇文章主要介紹“怎么理解Java API設(shè)計(jì)”，在日常操作中，相信很多人在怎么理解Java API設(shè)計(jì)問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對(duì)大家解答”怎么理解Java API設(shè)計(jì)”的疑惑有所幫助！接下來，請(qǐng)跟著小編一起來學(xué)習(xí)吧！
前言
了解在設(shè)計(jì) Java API 時(shí)應(yīng)該運(yùn)用的一些 API 設(shè)計(jì)實(shí)踐。這些實(shí)踐通常很有用，而且可確保 API 能在諸如 OSGi 和 Java Platform Module System (JPMS) 之類的模塊化環(huán)境中得到正確使用。有些實(shí)踐是規(guī)定性的，有些則是禁止性的。當(dāng)然，其他良好的 API 設(shè)計(jì)實(shí)踐也同樣適用。
OSGi 環(huán)境提供了一個(gè)模塊化運(yùn)行時(shí)，使用 Java 類加載器概念來強(qiáng)制實(shí)施類型可見性封裝。每個(gè)模塊都將有自己的類加載器，該加載器將連接到其他模塊的類加載器，以共享導(dǎo)出的包并使用導(dǎo)入的包。
Java 9 引入了 JPMS，后者提供了一個(gè)模塊化平臺(tái)，使用來自 Java 語言規(guī)范的訪問控制概念來強(qiáng)制實(shí)施類型可訪問性封裝。每個(gè)模塊都定義了哪些包將被導(dǎo)出，從而可供其他模塊訪問。默認(rèn)情況下，JMPS 層中的模塊都位于同一個(gè)類加載器中。
一個(gè)包可以包含一個(gè) API。這些 API 包的客戶端有兩種角色：API 使用者和 API 提供者。API 使用者使用 API 提供者實(shí)現(xiàn)的 API。
在以下設(shè)計(jì)實(shí)踐中，我們將討論包的公共部分。包的成員和類型不是公共的，或者說是受保護(hù)的（即私有或默認(rèn)可訪問的），無法從包的外部訪問它們，所以它們是包的實(shí)現(xiàn)細(xì)節(jié)。
Java 包必須是一個(gè)有凝聚力、穩(wěn)定的單元
Java 包的設(shè)計(jì)必須確保它是一個(gè)有凝聚力且穩(wěn)定的單元。在模塊化 Java 中，包是模塊之間共享的實(shí)體。一個(gè)模塊可以導(dǎo)出一個(gè)包，以便其他模塊可以使用這個(gè)包。因?yàn)榘窃谀K之間共享的單元，所以它必須有凝聚力，因?yàn)榘械乃蓄愋捅仨毰c包的特定用途相關(guān)。
不鼓勵(lì)使用混雜的包，比如 java.util，因?yàn)檫@種包中的類型通常是彼此不相關(guān)的。這類沒有凝聚力的包可能導(dǎo)致大量依賴項(xiàng)，因?yàn)榘牟幌嚓P(guān)部分會(huì)引用其他不相關(guān)的包，而且對(duì)包的某個(gè)方面的更改會(huì)影響依賴于此包的所有模塊，即使模塊可能并未實(shí)際使用該包的被修改部分。
由于包是一個(gè)共享單元，所以它的內(nèi)容必須是眾所周知的，而且隨著包在未來版本中的演變，只能以兼容方式更改所包含的 API。這意味著包不能支持 API 超集或子集；例如，可以將 javax.transaction 視為內(nèi)容不穩(wěn)定的包。
包的用戶必須能夠了解包中提供了哪些類型。這也意味著包應(yīng)由單個(gè)實(shí)體（例如一個(gè) jar 文件）提供，不得跨多個(gè)實(shí)體進(jìn)行拆分，因?yàn)樵摪挠脩舯仨氈勒麄€(gè)包的存在。
此外，該包必須以兼容方式實(shí)現(xiàn)在未來版本中的演變。因此，應(yīng)該對(duì)包進(jìn)行版本控制，而且其版本號(hào)必須根據(jù)語義版本控制規(guī)則進(jìn)行演變。
但最近我意識(shí)到，針對(duì)包的主版本更改的語義版本控制建議是錯(cuò)誤的。包的演變必須是功能的增加。在語義版本控制中，這會(huì)增加次要版本。
當(dāng)刪除功能時(shí)，您會(huì)對(duì)包執(zhí)行不兼容的更改，而不是增加主版本， 您必須改用一個(gè)新的包名，而讓原始包保持可兼容。在對(duì)包執(zhí)行不兼容的更改時(shí)，應(yīng)該改用新的包名，而不是更改主版本。
最小化包耦合
一個(gè)包中的類型可以引用其他包中的類型，例如，某個(gè)方法的參數(shù)類型和返回類型，以及某個(gè)字段的類型。這種包間耦合會(huì)在包上造成所謂的使用限制。這意味著 API 使用者必須使用 API 提供者引用的相同包，以便他們都能了解所引用的類型。
一般而言，我們希望最小化這種包耦合，以便最小化包上的使用限制。這可以簡化 OSGi 環(huán)境中的連接解析，并較大限度地減少依賴扇出，從而簡化部署。
接口優(yōu)先于類
對(duì)于 API，接口優(yōu)先于類。這是一種相當(dāng)常見的 API 設(shè)計(jì)實(shí)踐，對(duì)模塊化 Java 也很重要。接口的使用提高了實(shí)現(xiàn)的自由度，還支持多種實(shí)現(xiàn)。
接口對(duì)于讓 API 使用者與 API 提供者分離至關(guān)重要。無論是實(shí)現(xiàn)接口的 API 提供者，還是調(diào)用接口上的方法的 API 使用者，都允許使用包含 API 接口的包。
通過這種方式，API 使用者不會(huì)直接依賴于 API 提供者。它們都只依賴于 API 包。
除接口外，抽象類有時(shí)也是一種有效的設(shè)計(jì)選擇，但接口通常是選，尤其是考慮到接口的新改進(jìn)允許添加 default 方法。
最后，API 通常需要許多小的具體類，比如事件類型和異常類型。這沒什么問題，但這些類型通常應(yīng)該是不可變的且不被 API 使用者用來創(chuàng)建子類。
避免靜態(tài)
應(yīng)在 API 中要避免靜態(tài)。類型不應(yīng)包含靜態(tài)成員。靜態(tài)工廠也應(yīng)該避免。實(shí)例的創(chuàng)建應(yīng)與 API 分離。例如，API 使用者應(yīng)通過依賴注入或者 OSGi 服務(wù)注冊(cè)表或 jPMS 中的 java.util.ServiceLoader 之類的對(duì)象注冊(cè)表來接收 API 類型的對(duì)象實(shí)例。
避免靜態(tài)也是一種創(chuàng)建可測試的 API 的良好實(shí)踐，因?yàn)殪o態(tài)不容易模仿。
單例
API 設(shè)計(jì)中有時(shí)存在單例對(duì)象。但是，不應(yīng)通過靜態(tài) getInstance 方法或靜態(tài)字段等靜態(tài)對(duì)象來訪問單例對(duì)象。當(dāng)需要使用單例對(duì)象時(shí)，該對(duì)象應(yīng)由 API 定義為單例，并通過上文提到的依賴注入或?qū)ο笞?cè)表提供給 API 使用者。
避免類加載器假設(shè)
API 通常具有可擴(kuò)展性機(jī)制，API 使用者可在其中提供 API 提供者必須加載的類名。然后，API 提供者必須使用 Class.forName（可能使用線程上下文類加載器）來加載該類。這種機(jī)制會(huì)假定從 API 提供者（或線程上下文類加載器）到 API 使用者的類可見性。
API 設(shè)計(jì)必須避免類加載器假設(shè)。模塊化的一個(gè)主要特點(diǎn)是類型封裝。一個(gè)模塊（例如 API 提供者）不能對(duì)另一個(gè)模塊（例如 API 使用者）的實(shí)現(xiàn)細(xì)節(jié)具有可見性/可訪問性。
API 設(shè)計(jì)必須避免在 API 使用者與 API 提供者之間傳遞類名，而且必須避免與類加載器分層結(jié)構(gòu)和類型可視性/可訪問性有關(guān)的假設(shè)。
為了提供可擴(kuò)展性模型，API 設(shè)計(jì)應(yīng)讓 API 使用者將類對(duì)象，或者好將實(shí)例對(duì)象，傳遞給 API 提供者。這可以通過 API 中的一個(gè)方法或 OSGi 服務(wù)注冊(cè)表之類的對(duì)象注冊(cè)表來完成。請(qǐng)參見白板模式。
在 JPMS 模塊中不使用 java.util.ServiceLoader 類時(shí)，也會(huì)受到類加載器假設(shè)的影響，因?yàn)樗僭O(shè)所有提供者都對(duì)線程上下文類加載器或所提供的類加載器可見。
此假設(shè)在模塊化環(huán)境中通常是不成立的，但 JPMS 允許通過模塊聲明來聲明模塊提供或使用了一個(gè) ServiceLoader 托管服務(wù)。
不進(jìn)行持久性假設(shè)
許多 API 設(shè)計(jì)都假設(shè)只有一個(gè)構(gòu)造階段，對(duì)象在該階段被實(shí)例化并添加到 API，但是忽略了動(dòng)態(tài)系統(tǒng)中可能發(fā)生的解構(gòu)階段。
API 設(shè)計(jì)應(yīng)考慮到，對(duì)象可以添加，也可以刪除。例如，大多數(shù)監(jiān)聽器 API 都允許添加和刪除監(jiān)聽器。但是，許多 API 設(shè)計(jì)僅假設(shè)對(duì)象可以添加，并且從未刪除這些對(duì)象。例如，許多依賴注入系統(tǒng)無法撤銷注入的對(duì)象。
在 OSGi 環(huán)境中，可以添加和刪除模塊，因此能夠兼顧到此類動(dòng)態(tài)的 API 設(shè)計(jì)非常重要。OSGi Declarative Services 規(guī)范為OSGi 定義了一個(gè)依賴注入模型，該模型支持這些動(dòng)態(tài)操作，包括撤銷注入對(duì)象。
明確規(guī)定 API 使用者和 API 提供者的類型角色
如前言中所述，API 包的客戶端有兩種角色：API 使用者和 API 提供者。API 使用者使用 API，而 API 提供者實(shí)現(xiàn) API。對(duì)于 API 中的接口（和抽象類）類型，API 設(shè)計(jì)一定要明確規(guī)定哪些類型僅由 API 提供者實(shí)現(xiàn)，哪些類型可由 API 使用者實(shí)現(xiàn)。例如，監(jiān)聽器接口通常由 API 使用者實(shí)現(xiàn)，而實(shí)例被傳遞給 API 提供者。
API 提供者對(duì) API 使用者和 API 提供者實(shí)現(xiàn)的類型更改都很敏感。提供者必須實(shí)現(xiàn) API 提供者類型中的任何新更改，而且必須了解且可能調(diào)用 API 使用者類型中的任何新更改。
API 使用者通常可以忽略 API 提供者類型的（兼容）更改，除非它希望通過更改來調(diào)用新功能。但是 API 使用者對(duì) API 使用者類型的更改很敏感，而且可能需要修改才能實(shí)現(xiàn)新功能。
例如，在 javax.servlet 包中，ServletContext 類型由 API 提供者（比如 servlet 容器）實(shí)現(xiàn)。向 ServletContext 添加新方法需要更新所有 API 提供者來實(shí)現(xiàn)新方法，但 API 使用者無需執(zhí)行更改，除非他們希望調(diào)用該新方法。
但是，Servlet 類型由 API 使用者實(shí)現(xiàn)，向 Servlet 添加新方法需要修改所有 API 使用者來實(shí)現(xiàn)新方法，還需要修改所有 API 提供者來使用該新方法。因此，ServletContext 類型有一個(gè) API 提供者角色，Servlet 類型有一個(gè) API 使用者角色。
由于通常有許多 API 使用者和很少的 API 提供者，所以在考慮更改 API 使用者類型時(shí)，必須非常謹(jǐn)慎地執(zhí)行 API 演變，而 API 提供者類型更改的要求更加寬松。
這是因?yàn)椋恍枰纳贁?shù) API 提供者來支持更新的 API，但您不希望在更新 API 時(shí)需要更改許多現(xiàn)有的 API 使用者。僅當(dāng) API 使用者希望使用新 API 時(shí)，API 使用者才需要執(zhí)行更改。
OSGi Alliance 定義了文檔注釋、ProviderType 和 ConsumerType 來標(biāo)記 API 包中的類型角色。這些注釋包含在 osgi.annotation jar 中供您的 API 使用。
到此，關(guān)于“怎么理解Java API設(shè)計(jì)”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識(shí)，請(qǐng)繼續(xù)關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編會(huì)繼續(xù)努力為大家?guī)砀鄬?shí)用的文章！
重慶分公司
重慶分公司
