关于angular：继承和依赖注入

Inheritance and dependency injection

我有一组angular2组件，都应该注入一些服务。我首先想到的是，最好是创建一个超类并在其中注入服务。然后，我的任何组件都将扩展该超类，但是这种方法不起作用。

简化示例：

1
2
3
4
5
6
7
8
9
10
11

export class AbstractComponent {
constructor(private myservice: MyService) {
// Inject the service I need for all components
}
}

export MyComponent extends AbstractComponent {
constructor(private anotherService: AnotherService) {
super(); // This gives an error as super constructor needs an argument
}
}

我可以通过在每个组件中注入MyService并将该参数用于super()调用来解决此问题，但这绝对是荒谬的。

如何正确地组织我的组件，以便它们从超类继承服务？

相关讨论

I could solve this by injecting MyService within each and every component and use that argument for the super() call but that's definetly some kind of absurd.

这不是荒谬的。这就是构造函数和构造函数注入的工作方式。

每个可注入类都必须将依赖项声明为构造函数参数，如果超类也具有依赖项，则这些依赖项也必须在子类的构造函数中列出，并通过super(dep1, dep2)调用传递给超类。

绕过注入器并强制获取依赖项具有严重的缺点。

它隐藏了依赖关系，使代码更难阅读。
它违反了熟悉Angular2 DI的工作原理的期望。
它破坏了生成静态代码以替换声明性和命令性DI的脱机编译，从而提高了性能并减小了代码大小。

相关讨论

如果我必须将所需的服务从每个派生类传递到超类，则将其注入超类毫无意义。只需将其注入每个派生类中即可。更少的代码，更好的代码可读性。
当然，只需将其注入您实际需要的任何地方即可。如果您的超类具有一些依赖于它的实现，则将其添加到构造函数中，以便需要子类来传递它，否则就不要。
为了清楚起见：我在任何地方都需要它。尝试将该依赖关系移至我的超类，以便EACH派生类可以访问服务，而无需将其分别注入每个派生类。
您只需要在需要访问此服务的任何地方将其添加为依赖项即可。如果在超类中需要它，则还需要将其添加到每个子类中，因为子类的构造函数是首先将其注入的唯一方法。
那显然是不正确的(不再)，请参阅我对原始问题的编辑。
我认为是这样。请在您的问题下方查看我的评论。
他自己的问题的答案是丑陋的。这个问题已经说明了应该如何做。我详细说明了一些。
这个答案是正确的。 OP回答了他们自己的问题，但这样做违反了许多约定。您列出了实际的缺点也很有帮助，我会保证-我在想同样的事情。
我真的想(并继续)在OP" hack"上使用此答案。但是我不得不说，这似乎与DRY相去甚远，当我想在基类中添加依赖项时非常痛苦。我只需要将ctor注入(以及相应的super调用)添加到大约20多个类中，并且这个数字只会在将来增加。所以有两件事：1)我讨厌看到一个"大型代码库"来做这个；和2)感谢上帝的vim q和vscode ctrl+.
@ibgib在我所知道的所有语言中都是一样的。如果您想保证行为，构造函数将很困难。
我有一个同样的问题：我有很多组件都依赖于基于配置的同一初始全局注册，将代码放在基类中并让所有组件继承该行为似乎很优雅。注册和配置使用几种单例服务，其中一些仅在启动时才需要。但是，与依赖项注入相关的问题使子类化比其他方法更为混乱-创建一个实用程序服务以注入每个组件。值得考虑的是继承是否真的是您想要的。
我不明白为什么人们会如此沮丧，以至于他们不得不通过注入的服务。即使其他人很可爱，这个答案也是正确的-与其他语言一样。
@ktamlyn我也是这样看的。我的印象取决于您来自哪里。如果您来自Java或类似的语言，那么它是如何工作的，如果您来自JS，甚至导入也被认为是疯狂的样板，而构造函数是Illuminaty试图使每个开发人员疯狂的尝试;-)
您可以在Spring的超类中使用@Autowire属性，而不必在子类中将其作为构造函数参数传递吗？如果是这样，我会认为这是框架的局限性，不一定是其他每种语言(或框架)的工作方式。这也将使"隐藏依赖项"声明失去信誉，除非对于Spring开发人员而言这通常不是一个好习惯。免责声明：我不是java / spring专家，也不关心Illuminati。
我不知道你对Spring的意思。 Angular DI仅适用于构造函数参数，不适用于属性。隐藏依赖性不是目的。无论如何，我都不认为这是一种好处。
这不是很好的编码标准，您的答案是完全错误的。使代码更难阅读？您在说什么，如果您使用的是继承的类，那么在继承该类之前，应该先查看该类。其浪费和混乱。没有低级开发实践会遵循此方法。这就是为什么角钢是垃圾。
@thekevshow对于"您的答案是完全错误的"，我希望获得更多有关为什么我的答案错误的具体信息。您的评论听起来像是一团糟。当然，您可以尝试以不同的方式设计类，但是这种问题被问了很多遍，通常是关于"我如何才能再次满足在子类中指定所有参数的要求"。在我发布此答案之后，只有在子类不需要其他参数的情况下，Angular才开始支持超类中的构造函数。
@GnterZchbauer首先，始终首选从所需上下文中进行服务初始化，而不是通过Injectable / DI进行注入。服务应自力更生。这意味着超类可以引用不从引用和上下文向下链接到更高级别的类的对象，这些对象将其扩展以通过继承使用这些方法。同样以Java为例，您可以在基类中绑定bean并继承该类的属性，而无需通过构造函数传递依赖关系链。避免大量的混乱。
@GnterZchbauer其次，这不是应该推广的模式类型。这就是为什么存在资源工厂的原因。您为什么认为反应不遵循这种模式.........它不是语，最佳实践和高级开发，是不膨胀代码的行业标准，这也是函数编程变得越来越多的原因流行.......
Angular仅支持构造函数注入。您的评论与问题或我的答案没有任何关系。这是一个关于技术问题的问题，我回答了这个问题。您的评论是关于体系结构决策的。感谢您的详尽陈述。它仍然只是没有参数的语句列表，为什么您的语句是正确的。我认为这不是进行此类讨论的合适地点。
@GnterZchbauer我更批评尖锐的同意，对我一直在从事的一个项目感到非常恼火，目前出于上述原因将其移植为做出反应。但是您的评论似乎正在推动这是一种体系结构上的好处，而IMO我会说不是。
我不同意这个答案，因为即使这是Angular的良好做法。这不是编程的好方法，仅以以下示例为例：我有一个注入15个服务的基类，并被6个子类继承，DI列表不可读，当我必须添加一个服务或一个新子代时，它一个孩子/每个孩子变得非常复杂。
仅仅因为不方便并不意味着它是不好的做法。构造函数很不方便，因为很难可靠地完成对象初始化。我认为较差的做法是建立一个服务，该服务需要"注入15个服务并被6继承的基类"。

更新的解决方案，防止使用全局注入器生成myService的多个实例。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

import {Injector} from '@angular/core';
import {MyServiceA} from './myServiceA';
import {MyServiceB} from './myServiceB';
import {MyServiceC} from './myServiceC';

export class AbstractComponent {
protected myServiceA:MyServiceA;
protected myServiceB:MyServiceB;
protected myServiceC:MyServiceC;

constructor(injector: Injector) {
this.settingsServiceA = injector.get(MyServiceA);
this.settingsServiceB = injector.get(MyServiceB);
this.settingsServiceB = injector.get(MyServiceC);
}
}

export MyComponent extends AbstractComponent {
constructor(
private anotherService: AnotherService,
injector: Injector
) {
super(injector);

this.myServiceA.JustCallSomeMethod();
this.myServiceB.JustCallAnotherMethod();
this.myServiceC.JustOneMoreMethod();
}
}

这将确保MyService可以在扩展AbstractComponent的任何类中使用，而无需在每个派生类中注入MyService。

此解决方案有一些弊端(请参阅我原始问题下方的@GünterZ？chbauer的评论)：

仅当在许多地方需要注入几种不同的服务时，才注入全局注入器。如果您只有一项共享服务，那么最好在派生类中注入该服务。
我的解决方案和他提出的替代方案都有两个缺点，即它们使查看哪个类取决于什么服务变得更加困难。

有关Angular2中依赖注入的非常好的书面说明，请参阅此博客文章，该文章对我解决问题有很大帮助：http://blog.thoughtram.io/angular/2015/05/18/dependency-injection-in-angular- 2.html

相关讨论

我创建了一个提供服务的类，而不是手动注入所有服务，例如，它获取了注入的服务。然后将该类注入派生类中，并传递给基类。

派生类：

1
2
3
4
5
6
7
8
9

@Component({
...
providers: [ProviderService]
})
export class DerivedComponent extends BaseComponent {
constructor(protected providerService: ProviderService) {
super(providerService);
}
}

基类：

1
2
3
4
5

export class BaseComponent {
constructor(protected providerService: ProviderService) {
// do something with providerService
}
}

服务等级：

1
2
3
4
5

@Injectable()
export class ProviderService {
constructor(private _apiService: ApiService, private _authService: AuthService) {
}
}

相关讨论

据我了解，为了继承基类，您首先需要实例化它。为了实例化它，您需要传递其构造函数所需的参数，这样就可以通过super()调用将它们从子级传递到父级，这样才有意义。当然，喷油器是另一种可行的解决方案。

而不是注入将所有其他服务作为依赖项的服务，如下所示：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

class ProviderService {
constructor(private service1: Service1, private service2: Service2) {}
}

class BaseComponent {
constructor(protected providerService: ProviderService) {}

ngOnInit() {
// Access to all application services with providerService
this.providerService.service1
}
}

class DerivedComponent extends BaseComponent {
ngOnInit() {
// Access to all application services with providerService
this.providerService.service1
}
}

我将跳过此额外的步骤，只需在BaseComponent中添加注入所有服务，如下所示：

1
2
3
4
5
6
7
8
9
10

class BaseComponent {
constructor(protected service1: Service1, protected service2: Service2) {}
}

class DerivedComponent extends BaseComponent {
ngOnInit() {
this.service1;
this.service2;
}
}

该技术假设两件事：

您的关注与组件继承完全相关。您最有可能落在这个问题上的原因是因为您需要在每个派生类中重复大量的非干燥(WET？)代码。如果您希望所有组件和服务都受益于单个入口点，则需要执行额外的步骤。

每个组件都扩展BaseComponent

如果决定使用派生类的构造函数，则还有一个缺点，因为您将需要调用super()并传入所有依赖项。尽管我没有真正看到用例需要使用constructor而不是ngOnInit，但完全有可能存在这种用例。

相关讨论

丑陋的哈克

前段时间，我的一些客户希望将两个BIG角度项目加入到昨天(角度v4到角度v8)。 Project v4对每个组件使用BaseView类，并且包含用于翻译的tr(key)方法(在v8中，我使用ng-translate)。因此，为避免切换翻译系统并并行编辑数百个模板(在v4中)或设置2翻译系统，我使用了以下丑陋的技巧(我对此并不感到骄傲)-在AppModule类中，我添加了以下构造函数：

1
2
3
4
5

export class AppModule {
constructor(private injector: Injector) {
window['UglyHackInjector'] = this.injector;
}
}

现在可以使用AbstractComponent

1
2
3
4
5
6
7

export class AbstractComponent {
private myservice: MyService = null;

constructor() {
this.myservice = window['UglyHackInjector'].get(MyService);
}
}

相关讨论

如果父类是从第三方插件获得的(并且您无法更改源代码)，则可以执行以下操作：

1
2
3
4
5
6
7
8
9
10

import { Injector } from '@angular/core';

export MyComponent extends AbstractComponent {
constructor(
protected injector: Injector,
private anotherService: AnotherService
) {
super(injector.get(MyService));
}
}

或更好的方法(仅在构造函数中保留一个参数)：

1
2
3
4
5
6
7
8
9
10
11
12

import { Injector } from '@angular/core';

export MyComponent extends AbstractComponent {
private anotherService: AnotherService;

constructor(
protected injector: Injector
) {
super(injector.get(MyService));
this.anotherService = injector.get(AnotherService);
}
}