与导出服务类并将其用于类型信息相比,为 angular.service 创建接口(interface)有什么优势?
例子:
class Dashboard {
constructor(ui: IUiService){}
}
对比
class Dashboard {
constructor(ui: UiService){}
}
有性能优势吗?如果我只使用服务类来获取类型信息会怎样?
除非您对可以使用但具有共同基础的服务有不同的实现,否则这似乎是没有任何好处的额外工作。或者当您想在单元测试中模拟服务而不是直接使用它们时。
编辑:我很想知道 typescript 编译器会对仅用于类型信息的导入做些什么。它会调用构造函数还是添加到 require 语句 (ES6)?它会新建一个类的实例吗?
最佳答案
这不是一个 TypeScript 问题,这是一个“接口(interface)有什么好处” (简而言之)答案是:客户端不应该“知道”所请求服务的真正实现是什么。 你今天的 UiService 足以满足你的需求,但有一天你可能会有另一个实现它,甚至你想在你的测试中模拟它。
另一种情况是,UiService 由 ProUiService 扩展到您的整个系统,您将不得不遍历整个系统并更改您的注入(inject)类型,而实际上并不需要它。
如前所述:客户端不应该知道所请求服务的真正实现是什么。
编辑(回复编辑):
TypeScript 编译器不会“知道”在哪里选择这些类型类/接口(interface),您必须在代码中使用 tsconfig.json 或引用(注释)让 TypeScript 了解此声明的定义位置。它是否是类的类型并不重要。
重要的是要理解,当您导入(ES6 风格)一个类并且从未真正使用它(仅将其用作类型定义)时,它会被编译器删除,因为类型在 JavaScript 中并不真正存在。 但是,如果你使用它。例如:
var ui = new UiService(); // This will generate a javascript code
编译器不会删除导入语句。
关于angularjs - 使用 TypeScript 接口(interface)获取类型信息的 angular.service 的目的是什么,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/32125207/