0

我正在查看in-memory-web-api的实现，并且有以下代码：

@Injectable()
export class InMemoryBackendService {
  protected config: InMemoryBackendConfigArgs = new InMemoryBackendConfig();
            ^^^^^^
  ...

      constructor(
        @Inject(InMemoryBackendConfig) @Optional() config: InMemoryBackendConfigArgs 
                                                   ^^^^^^
        ) {
        ...

据我了解，模式如下：

  1. 定义类属性并在不使用 DI 的情况下实例化依赖项
  2. 可选地注入依赖项

如果用户通过 DI 提供修改后的依赖项，它将被注入，并且没有 DI 实例化的默认依赖项将被覆盖。我怀疑模块RequestOptions中可能有类似的东西。HTTP

这是一种常见的模式吗？

编辑：

事实证明，这in-memory-web-api并不完全是我要问的模式。假设，我有一个类A使用B可注入的类实例和 token B。所以他们都注册了根注入器：

提供者：[A，B]

现在，如果用户想要自定义B，他可以在同一个令牌下注册自定义版本，从而有效地覆盖原来的B：

providers: [{provide:B, useClass: extendedB}]`

这是如何RequestOptions在http模块中扩展的。

4

1 回答 1

2

默认值不仅被覆盖。这里最重要的部分是

Object.assign(this.config, config || {})

没有它什么都不会发生。

此模式并非特定于 DI，它是默认属性值的常见配方，类似于_.defaults.

我想说InMemoryBackendConfig 默认实现在这里是无用的抽象。由于this.config总是与 合并config，前者可能只是一个普通对象

  protected config: InMemoryBackendConfigArgs = { ... };

InMemoryBackendConfig并RequestOptions使用这种模式的复杂变体。是的，在最基本的形式中，这是可以做到的：

providers: [{provide:B, useClass: extendedB}]`

constant这种模式被AngularJS 中的服务广泛用于配置对象，但是B作为类而不是普通对象允许扩展原始值而不是替换它们。

于 2017-02-20T15:48:55.313 回答