我很难理解DI，而不是与Angular 2有关，我认为只是设计模式。阅读这里的文档，从非DI开始，然后展示DI未来如何证明类。
没有DI：
public engine: Engine;
public tires: Tires;
public description = 'No DI';
constructor() {
this.engine = new Engine();
this.tires = new Tires();
}
如果Engine类发展并且其构造函数需要参数怎么办？这会破坏Car类，它会一直被打破，直到你按照this.engine = new Engine（theNewParameter）的行重写它。当您第一次编写Car时，引擎构造函数参数甚至不是一个考虑因素。你现在也许不会预料到它们。但是你必须开始关心，因为当Engine的定义发生变化时，Car类必须改变。这让汽车变得脆弱。
我理解那部分。
文档有DI的例子：
public description = 'DI';
constructor(public engine: Engine, public tires: Tires) { }
Docs现在解释它是消费者的问题，我理解。
如果您只是简单地列出您想要构建的内容而不必定义哪个依赖项被注入到什么内容，那不是很好吗？
这是依赖注入框架发挥作用的地方。想象一下，这个框架有一个叫做注入器的东西。您使用此注入器注册了一些类，并确定了如何创建它们。
当你需要一辆汽车时，你只需让喷油器为你取得它就可以了。你好了。
如果注入的服务或类中的代码发生更改，请使用Angular的DI。所有消费者都必须改变。如果有一些消费者类使用该服务然后服务改变其中一个功能，如果他们使用该功能，则所有消费者必须更新代码。为了分离关注点，是否只是为了保持课外和消费者代码的维护？请澄清并帮助我理解Angular 2中的依赖注入。