本文记录我在工作中的一次失误。
如下图所示，我在构造函数里注入了一个新的依赖：
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 库，请考虑更改的广泛后果，并尝试预测可能出现的任何问题。
