本文記錄我在工作中的一次失誤。

如下圖所示，我在構造函數里注入了一個新的依賴：

protected checkoutService: CheckoutService

當下列情況同時滿足時，客戶就會遇到編譯錯誤：

(1) 客戶升級到了新的 minor 版本，即我引入該新的依賴的版本。
(2) 客戶之前擴展了 CheckoutDeliveryService
(3) 客戶在自己的擴展類的構造函數里，調用了 super 即父類的構造函數。

因為客戶是從舊版本升級上來的，所以構造函數里沒有傳遞我這個新版本引入的 checkoutService 輸入參數，所以會遇到語法錯誤。

正確的做法如下圖所示：

export class CheckoutDeliveryService implements CheckoutDeliveryFacade {constructor(protected checkoutStore: Store<StateWithCheckout>,protected processStateStore: Store<StateWithProcess<void>>,protected activeCartService: ActiveCartService,protected userIdService: UserIdService,@Optional() protected checkoutService?: CheckoutService) {}

使用 @Optional 來修飾這個新引入的構造函數輸入參數。

同時，在代碼里的邏輯也需要改變，需要同時處理 checkoutService 為空或者不為空的情況。

protected isCheckoutDetailsLoading$: Observable<boolean> = this.checkoutService? this.checkoutService.isLoading(): this.checkoutStore.pipe(select(CheckoutSelectors.getCheckoutLoading));

如果 checkoutService 不為空，則使用 checkoutService.isLoading 返回的 Observable；否則，就為舊版本的情況，使用舊版本的實現，從 checkoutStore 里取出 checkout loading 的讀取狀態。

修改了服務代碼之后，也會影響到對應的單元測試代碼。

如今的 isSetDeliveryModeBusy 標志位，決定其值的輸入條件之二，從 checkoutService.isLoading, 更改成了 isCheckoutDetailsLoading.

因此，在單元測試代碼里，我們需要創建一個全局的 isCheckoutLoading$ Observable 對象：

然后創建一個 mockCheckoutService 類，內部返回這個全局的 isCheckoutLoading$ Observable 對象。

這樣，在任何時候我們需要修改 CheckoutService.isLoading 的返回值時，通過調用 isCheckoutLoading$ 的 next 方法即可靈活控制。

需要強調的是，在大型 API 中保持穩定性是一項挑戰。 如果您要更改 API 庫，請考慮更改的廣泛后果，并嘗試預測可能出現的任何問題。

更多Jerry的原創文章，盡在：“汪子熙”.

總結

以上是生活随笔為你收集整理的避免修改构造函数输入参数引起的 breaking change的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。