javascript - Angular/Typescript——通过示例解释接口(interface)的好处

Question

作为前言，我对 Javascript 非常熟悉，并且在 Angular 方面表现出色，直到我看到它在使用 Typescript 的项目中实现。在不断攀爬 Angular 的学习曲线和看到 TS 的这种新实现方式之间，这让我感到不知所措。

我暂停了 AngularJS 的低级学习，并开始复习使用我们当前正在使用的技术的教程:Angular。 Typescript 和带有 WebApi 的 Entity Framework 。

我遇到了这个例子:https://blogs.msdn.microsoft.com/tess/2015/12/10/3b-services-getting-started-with-angularjs-typescript-and-asp-net-web-api/

对于我的实际问题，在作者开始实现他的服务之前我做得很好。我正在考虑如何处理它(使用我之前研究和学到的东西)，作者用一个接口(interface)来描述服务本身来打动我:

Create the DataAccessService

1. Create a new DataAccessService.ts file under app/common/services
2. Add an Interface describing the DataAccessService

module app.common.services {
    interface IDataAccessService {
        getStoreResource(): ng.resource.IResourceClass<IStoreResource>;
    }
}

好吧，从我的 Angular 来看，他创建了一个函数，将被调用来获取他想要的资源，但是这个实现有什么好处，特别是对于接口(interface)(IDataAccessService)？然后他深入兔子洞并创建另一个接口(interface)(IStoreResource)来返回另一个接口(interface)(IStores)的资源:

The DataAccessService will just give us access to the various API’s we may be using, in this case a resource for the stores API. We could also have methods here for getAdResource() or getProductResource() for example if we had APIs to get ads or products or similar. We tell it to return a ng.resource.IResourceClass so we’ll have to define what that is.

Declare the IStoreResource as a resource of IStores… this is to explain what types of items will be returned from or passed to the resource. This should go above the interface declaration for IDataAccessService

interface IStoreResource extends ng.resource.IResource<app.domain.IStore> { }

此时很迷茫，但它仍在继续:

Next we’re going to implement the DataAccessService below the IDataAccessService interface

export class DataAccessService implements IDataAccessService {
   //minification protection
   static $inject = ["$resource"]
   constructor(private $resource: ng.resource.IResourceService) { }

   getStoreResource(): ng.resource.IResourceClass<IStoreResource> {
      return this.$resource("/api/stores/:id");
   }
}

我更好地理解了这一点，因为它看起来是在做实际工作。我们已经有了函数，可以让我们的资源 API 返回我们需要的数据。但在我看来(这可能是我缺乏 OOP 知识的地方)，这些切换和实现只是增加了复杂性，而且我看不到好处。

有人可以用 ELI5 或更通俗的方法来解释这一点吗？谢谢!

Answer 1

这确实是 TypeScript 的闪光点，它为 JavaScript 的面向对象编程带来了一种更经典的方法。但首先，您需要知道您的SOLID principles ，特别是在这种情况下，依赖倒置原则(如 toskv 的评论中所述)，其中指出:

• 高级模块不应依赖于低级模块。两者都应该依赖于抽象。
• 抽象不应依赖于细节。细节应取决于抽象。

为了将其置于上下文中，接口(interface)用于描述对象执行给定任务所需的功能契约。

具体对象然后实现提供行为的接口(interface)。依赖关系应该通过接口(interface)公开，而不是具体对象，因为这允许松散耦合并具有可测试性等多个优点。