譯者 | 劉汪洋

審校 | 重樓

對于軟件開發(fā)者而言，編寫可重用的代碼是一項基本而重要的技能。每位工程師都應(yīng)掌握如何盡可能地提高代碼的復(fù)用性。當(dāng)前，一些開發(fā)人員可能會認(rèn)為微服務(wù)的本質(zhì)是小而高效，因此他們無需編寫高質(zhì)量代碼。然而，即便是微服務(wù)，在變得龐大時，閱讀和理解代碼的時間成本也會迅速增加至編寫時的十倍。

代碼一開始編寫得不佳，將會大幅增加修復(fù) bug 或添加新功能的工作量。在一些極端情況下，我見證過團(tuán)隊因代碼質(zhì)量問題而放棄原有代碼，重新編寫。這不僅浪費(fèi)了寶貴時間，還可能導(dǎo)致開發(fā)人員承擔(dān)責(zé)任并失去工作。

本文將介紹經(jīng)過實踐驗證的提高Java 中代碼可重用性的八條指導(dǎo)原則。

Java 編程中編寫可重用代碼的八大指導(dǎo)原則

1. 制定編碼規(guī)范
2. 記錄 API 文檔
3. 遵守代碼命名規(guī)范
4. 提高代碼內(nèi)聚性
5. 代碼解耦
6. 遵循 SOLID 原則
7. 合理運(yùn)用設(shè)計模式
8. 避免重復(fù)造輪子

制定編碼規(guī)范

編寫可重用代碼的首要步驟是與團(tuán)隊一同確立代碼規(guī)范。如果對編碼規(guī)范不能達(dá)成共識，代碼很快就會變得混亂不堪。如果團(tuán)隊成員之間意見不統(tǒng)一，關(guān)于代碼實現(xiàn)的無效討論也會頻繁發(fā)生。同時，你需要確立一個基礎(chǔ)的代碼設(shè)計框架，以解決軟件需要解決的問題。

在制定了標(biāo)準(zhǔn)和代碼設(shè)計框架之后，接下來應(yīng)當(dāng)明確代碼指導(dǎo)原則。

常見的指導(dǎo)原則包括：

• 代碼命名規(guī)范
• 類和方法的行數(shù)限制
• 異常處理方式
• 包結(jié)構(gòu)設(shè)計
• 編程語言及其版本
• 所使用的框架、工具和庫
• 代碼測試標(biāo)準(zhǔn)
• 代碼結(jié)構(gòu)層次（如控制器、服務(wù)、存儲庫、領(lǐng)域等）

一旦團(tuán)隊就這些規(guī)范達(dá)成共識，每個成員都應(yīng)對代碼審查負(fù)責(zé)，以確保編寫出高質(zhì)量、可重用的代碼。如果沒有共識，寫出高質(zhì)量且可重用的代碼幾乎不可能。

記錄 API 文檔

當(dāng)創(chuàng)建服務(wù)并以 API 形式公開時，應(yīng)該詳細(xì)記錄 API 信息，以便新加入的開發(fā)人員能夠輕松理解和使用。

API 在微服務(wù)架構(gòu)中扮演著重要角色。因此，對你的項目不太熟悉的其他團(tuán)隊成員必須能夠通過閱讀 API 文檔來理解其功能。如果 API 文檔記錄不當(dāng)，代碼的重復(fù)編寫風(fēng)險會增加。新開發(fā)人員可能會無意中創(chuàng)建一個和現(xiàn)有功能重復(fù)的方法。

因此，精確記錄 API 至關(guān)重要。但在代碼中過度使用文檔可能并無益處。應(yīng)該只記錄 API 中的關(guān)鍵信息，如業(yè)務(wù)操作的解釋、參數(shù)、返回值對象等。

遵守代碼命名規(guī)范

簡潔且具有描述性的代碼命名總是優(yōu)于晦澀難懂的縮寫。瀏覽不熟悉的代碼庫時，我發(fā)現(xiàn)縮寫往往難以讓人立即理解其含義。

因此，相較于使用像Ctr這樣的縮寫，直接命名為Customer更為明晰和有意義。Ctr可能代表了合同（contract）、控制（control）、客戶（customer）等多種含義，使人難以確定其準(zhǔn)確意圖。

此外，要遵循你所使用編程語言的命名規(guī)范。以 Java 為例，它有 JavaBeans 命名規(guī)范，這對每個 Java 開發(fā)者來說都是基本常識。以下是 Java 中類、方法、變量和包的命名方式：

• 類名采用 PascalCase（帕斯卡命名法）：如CustomerContract
• 方法和變量采用 camelCase（駝峰命名法）：如customerContract
• 包名全部小寫：如service

提高代碼內(nèi)聚性

內(nèi)聚的代碼應(yīng)該專注于_做好一件事_。雖然這是一個簡單的概念，但即便是經(jīng)驗豐富的開發(fā)人員也常常忽視它。這樣，他們就會創(chuàng)建出所謂的_超級復(fù)雜類_，即一個承擔(dān)了過多職責(zé)的類，有時也被稱為_全能類_。

要實現(xiàn)高內(nèi)聚的代碼，關(guān)鍵是學(xué)會拆分代碼，確保每個類和方法專注于單一職責(zé)。比如，如果你創(chuàng)建了一個名為saveCustomer的方法，它應(yīng)當(dāng)只負(fù)責(zé)一個動作：保存客戶信息。它不應(yīng)該同時負(fù)責(zé)更新和刪除客戶信息。

同理，如果有一個名為CustomerService的類，它應(yīng)該僅包含與客戶相關(guān)的功能。如果CustomerService類中有執(zhí)行產(chǎn)品相關(guān)操作的方法，應(yīng)移至ProductService類中。

與其在CustomerService類中添加執(zhí)行產(chǎn)品操作的方法，不如在該類中引用ProductService，并調(diào)用我們所需的任何方法。

為了更清晰地介紹這個概念，我們來分析一個低內(nèi)聚的類示例：

public class CustomerPurchaseService {

    public void saveCustomerPurchase(CustomerPurchase customerPurchase) {
         // 執(zhí)行與客戶相關(guān)的操作
        registerProduct(customerPurchase.getProduct());
         // 更新客戶信息
         // 刪除客戶信息
    }

    private void registerProduct(Product product) {
         // 在客戶領(lǐng)域中執(zhí)行對產(chǎn)品的邏輯操作…
    }

}

這個類存在以下問題：

• saveCustomerPurchase方法不止注冊產(chǎn)品，還涉及到更新和刪除客戶的操作。這個方法承擔(dān)了過多的職責(zé)。
• registerProduct方法在當(dāng)前位置難以被其他開發(fā)者發(fā)現(xiàn)。因此，如果其他開發(fā)者需要類似的功能，可能會不必要地重寫這個方法。
• registerProduct方法處于不恰當(dāng)?shù)念I(lǐng)域。CustomerPurchaseService不應(yīng)負(fù)責(zé)注冊產(chǎn)品。
• saveCustomerPurchase方法調(diào)用了一個私有方法，而不是委托給專門處理產(chǎn)品操作的外部類。

識別出這些問題后，我們可以重新編寫這段代碼，使其變得更加內(nèi)聚。我們將registerProduct方法移動到更合適的位置，即ProductService類中。這樣做使代碼更易于搜索和重用，同時避免將此方法局限在CustomerPurchaseService中：

public class CustomerPurchaseService {

    private ProductService productService;

    public CustomerPurchaseService(ProductService productService) {
      this.productService = productService;
    }

    public void saveCustomerPurchase(CustomerPurchase customerPurchase) {
         // 僅執(zhí)行與客戶購買相關(guān)的操作
        productService.registerProduct(customerPurchase.getProduct());
    }

}

public class ProductService {

   public void registerProduct(Product product) {
         // 在產(chǎn)品領(lǐng)域中執(zhí)行相關(guān)邏輯…
    }
}

在這個改進(jìn)后的版本中，saveCustomerPurchase僅執(zhí)行其主要職責(zé)：保存客戶購買信息。同時，registerProduct方法的職責(zé)被正確地委托給了ProductService類，從而使兩個類都更加專注和內(nèi)聚。現(xiàn)在，這些類及其方法都專注于執(zhí)行預(yù)期的特定任務(wù)。

代碼解耦

_高度耦合的代碼_指的是那些具有過多依賴關(guān)系的代碼，這種情況會導(dǎo)致代碼難以維護(hù)。類中定義的依賴（其他類）越多，其耦合程度就越高。

微服務(wù)架構(gòu)的目標(biāo)之一就是將服務(wù)解耦，如果一個微服務(wù)與其他服務(wù)都有連接，那么它就會高度耦合。

想要更好地實現(xiàn)代碼復(fù)用，就需要盡可能使系統(tǒng)和代碼各自獨(dú)立。雖然服務(wù)和代碼之間的通信不可避免會產(chǎn)生一定程度的耦合，但關(guān)鍵在于讓這些服務(wù)盡可能保持獨(dú)立性。

下面是一個高度耦合類的例子：

public class CustomerOrderService {

  private ProductService productService;
  private OrderService orderService;
  private CustomerPaymentRepository customerPaymentRepository;
  private CustomerDiscountRepository customerDiscountRepository;
  private CustomerContractRepository customerContractRepository;
  private CustomerOrderRepository customerOrderRepository;
  private CustomerGiftCardRepository customerGiftCardRepository;

  // 其他方法…
}

注意CustomerService類與許多其他服務(wù)類的耦合程度很高。這么多的依賴意味著該類將包含大量代碼，這不利于代碼的測試和維護(hù)。

更有效的方法是拆分這個類，創(chuàng)造多個依賴更少的服務(wù)。我們可以通過將CustomerService類分解為獨(dú)立的服務(wù)來降低其耦合度：

public class CustomerOrderService {

  private OrderService orderService;
  private CustomerPaymentService customerPaymentService;
  private CustomerDiscountService customerDiscountService;

  // 省略其他方法…
}

public class CustomerPaymentService {

  private ProductService productService;
  private CustomerPaymentRepository customerPaymentRepository;
  private CustomerContractRepository customerContractRepository;
  
  // 省略其他方法…
}

public class CustomerDiscountService {
  private CustomerDiscountRepository customerDiscountRepository;
  private CustomerGiftCardRepository customerGiftCardRepository;

  // 省略其他方法…
}

經(jīng)過這樣的重構(gòu)，CustomerService及其他類變得更易于進(jìn)行單元測試，同時也更便于維護(hù)。類的職責(zé)越單一且清晰，就越容易實現(xiàn)新功能。如果出現(xiàn) bug，也更容易進(jìn)行修復(fù)。

遵循 SOLID 原則

SOLID 代表面向?qū)ο缶幊蹋∣OP)中五個關(guān)鍵的設(shè)計原則，它們的目標(biāo)是使軟件系統(tǒng)更加可維護(hù)、靈活，并易于理解。
下面是這些原則的簡要說明：

• 單一職責(zé)原則（SRP）：一個類應(yīng)該僅承擔(dān)一個職責(zé)或目標(biāo)，并且完全封裝這個職責(zé)。這個原則促進(jìn)_高內(nèi)聚_，幫助保持類的專注和易于管理。
• 開放封閉原則（OCP）：軟件實體（如類、模塊、函數(shù)等）應(yīng)該對擴(kuò)展開放，對修改封閉。應(yīng)設(shè)計代碼以便在不更改現(xiàn)有代碼的情況下增加新功能，從而減少更改的影響并促進(jìn)代碼重用。
• 里氏替換原則（LSP）：超類的任何實例都應(yīng)該能被其子類的實例替換，而不影響程序的正確性。換言之，基類的任何實例都應(yīng)該可以用其派生類的實例替換，保證程序行為的一致性。
• 接口隔離原則（ISP）：客戶端不應(yīng)被迫依賴它們不需要的接口。建議將大型接口拆分為更小且更具體的接口，使得客戶端僅需依賴它們真正需要的接口。這有助于松耦合和避免不必要的依賴。
• 依賴反轉(zhuǎn)原則（DIP）：高層模塊不應(yīng)依賴低層模塊，兩者都應(yīng)依賴抽象。鼓勵使用抽象（接口或抽象類）來解耦高層模塊和低層實現(xiàn)細(xì)節(jié)，促進(jìn)基于抽象而非具體實現(xiàn)的依賴。

遵循這些 SOLID 原則有助于開發(fā)者編寫更模塊化、可維護(hù)且易于擴(kuò)展的代碼。這些原則有助于實現(xiàn)更易于理解、測試和修改的代碼，從而形成更健壯、適應(yīng)性更強(qiáng)的軟件系統(tǒng)。

合理運(yùn)用設(shè)計模式

設(shè)計模式是經(jīng)驗豐富的開發(fā)者在處理多種編碼場景后總結(jié)出的最佳實踐。恰當(dāng)?shù)厥褂迷O(shè)計模式可以顯著提升代碼的復(fù)用性。

掌握設(shè)計模式還能增強(qiáng)你閱讀和理解代碼的能力——這包括 JDK 中的代碼。當(dāng)你能識別出其背后的設(shè)計模式時，代碼會變得更加清晰。

盡管設(shè)計模式有其用處，但并非每種模式適用于所有情況，因此使用時需謹(jǐn)慎。僅僅因為我們了解某個模式，并不意味著就應(yīng)該隨意應(yīng)用。在不恰當(dāng)?shù)膱鼍爸惺褂迷O(shè)計模式可能會使代碼變得更復(fù)雜、更難以維護(hù)。然而，在合適的場合應(yīng)用設(shè)計模式，可以使代碼更加靈活和易于擴(kuò)展。

以下是面向?qū)ο缶幊讨谐Ｒ姷脑O(shè)計模式簡要概述：

創(chuàng)建型模式

• 單例（Singleton）：確保一個類僅有一個實例，并提供一個全局訪問點(diǎn)。
• 工廠方法（Factory Method）：定義一個用于創(chuàng)建對象的接口，但由子類決定實例化哪個類。
• 抽象工廠（Abstract Factory）：提供一個接口，用于創(chuàng)建相關(guān)或依賴對象的族群。
• 建造者（Builder）：分離復(fù)雜對象的構(gòu)建和表示。
• 原型（Prototype）：通過復(fù)制現(xiàn)有的實例來創(chuàng)建新實例。

結(jié)構(gòu)型模式

• 適配器（Adapter）：將一個類的接口轉(zhuǎn)換成客戶端所期望的另一種接口。
• 裝飾器（Decorator）：動態(tài)地為對象添加新的功能。
• 代理（Proxy）：為另一個對象提供一個代理或占位符，以控制對這個對象的訪問。
• 組合（Composite）：將對象組合成樹形結(jié)構(gòu)，以表示部分整體的層次結(jié)構(gòu)。
• 橋接（Bridge）：將抽象部分與其實現(xiàn)部分分離，使它們可以獨(dú)立變化。

行為型模式

• 觀察者：在對象間建立一種一對多的依賴關(guān)系，使得當(dāng)一個對象改變狀態(tài)時，所有依賴它的對象都會自動收到通知并更新。
• 策略：封裝了一系列算法，并在運(yùn)行時允許選擇其中的一種。
• 模板方法：在基類中定義一個算法的框架，并允許子類提供具體的實現(xiàn)。
• 命令：將請求或簡單操作封裝成對象，這使得你可以使用不同的請求、隊列或日志請求，并支持可撤銷的操作。
• 狀態(tài)：當(dāng)對象的內(nèi)部狀態(tài)改變時，允許對象改變其行為。
• 迭代器：提供一種方法來順序訪問聚合對象的元素，而無需暴露其底層表示。
• 責(zé)任鏈：允許請求沿著處理者鏈傳遞，直到一個處理者處理它。
• 中介者：定義一個對象，該對象封裝了一組對象如何交互的方式，從而促進(jìn)它們之間的松散耦合。
• 訪問者：將算法從操作的對象中分離出來，將算法封裝到一個稱為訪問者的對象中。

并不需要記住每一種設(shè)計模式，重要的是意識到這些模式的存在，并理解它們各自的使用場景。這樣，你就能夠根據(jù)具體的編程情境選擇最合適的設(shè)計模式。

避免重復(fù)造輪子

許多公司在沒有充分理由的情況下仍選擇使用內(nèi)部框架，但這對非大型科技公司來說通常是不現(xiàn)實的。對于中小型企業(yè)來說，與開源社區(qū)或大型科技公司競爭，開發(fā)出更優(yōu)解決方案的可能性較低。

相比于重復(fù)發(fā)明輪子和制造不必要的工作，更理智的選擇是直接利用已有的工具和技術(shù)。這不僅節(jié)省時間，還有助于開發(fā)人員的職業(yè)發(fā)展，因為他們無需學(xué)習(xí)只在公司內(nèi)部使用的框架。

例如，Hibernate 是一個經(jīng)過嚴(yán)格測試并被廣泛使用的持久性框架。我遇到過的一家公司選擇使用自己的內(nèi)部框架進(jìn)行持久化處理，盡管它并不具備 Hibernate 的全部功能和穩(wěn)定性。維護(hù)和擴(kuò)展這種內(nèi)部框架給公司帶來了額外負(fù)擔(dān)，而沒有帶來相應(yīng)的好處。

因此，建議盡可能使用市場上廣泛可用且流行的技術(shù)和工具。開發(fā)一個能與成熟開源軟件匹敵的框架幾乎不可能，因為后者是眾多才華橫溢的開發(fā)者多年合作的成果。此外，許多大型公司也支持開源項目，確保它們能按預(yù)期運(yùn)行。

結(jié)論

理解和應(yīng)用代碼復(fù)用性的關(guān)鍵原則對于構(gòu)建高效且可維護(hù)的軟件系統(tǒng)至關(guān)重要。通過掌握抽象、封裝、關(guān)注點(diǎn)分離、標(biāo)準(zhǔn)化和文檔化等關(guān)鍵概念，開發(fā)人員能創(chuàng)建可節(jié)省時間和減少重復(fù)工作的組件，同時提升代碼質(zhì)量。

設(shè)計模式對代碼復(fù)用至關(guān)重要，提供了針對常見設(shè)計問題的經(jīng)過驗證過的解決方案。內(nèi)聚性和低耦合確保組件獨(dú)立且依賴性最小，提高了它們的復(fù)用性。遵循 SOLID 原則有助于創(chuàng)建模塊化、可擴(kuò)展的代碼，易于集成到不同項目中。

編寫可復(fù)用代碼能夠為開發(fā)人員帶來諸多好處，包括提高生產(chǎn)力、加強(qiáng)協(xié)作和加快開發(fā)周期。可復(fù)用代碼使項目迭代更快、維護(hù)更容易，能夠有效利用現(xiàn)有解決方案。總之，掌握代碼復(fù)用性的核心原則能夠幫助開發(fā)人員構(gòu)建可擴(kuò)展、適應(yīng)性強(qiáng)且面向未來的軟件系統(tǒng)。

譯者介紹

劉汪洋，51CTO社區(qū)編輯，昵稱：明明如月，一個擁有 5 年開發(fā)經(jīng)驗的某大廠高級 Java 工程師，擁有多個主流技術(shù)博客平臺博客專家稱號。

原文標(biāo)題：How to write reusable Java code，作者：Rafael del Nero