为什么建议将服务契约定义为接口

主要目标是将服务的定义与实现分开

您的服务的用户不应该知道您如何实现服务,但是他应该知道他可以做什么操作以及如何做。

这就是为什么它使用接口而不是类,因为接口不包含实现。

您可以一次共享您的接口,然后即使您每天都更改其方法的实现,也不会担心数年。最终用户不需要重新编译使用您的服务的代码。

当然[有几个优点]!

主要的一个可能是实现 倍数 支持所述接口并使用这些类的类 可互换的 [关于特定接口]。它的一个直接用途是与用于测试的模拟类一起使用;它也与IOC(控制反转)模式一起使用,更普遍地说,在我们关心“什么”而不是“谁”的任何地方,也就是说,重要的是,无论哪个类已经就位,它都会按照合同(API)不管是谁(哪个班)。

接口的另一个显著优势是 模块化行为 . 例如,您的应用程序可以实现一个工作原理,比如列表(可以迭代,提供许多项等)。 和 像一个小部件验证程序(一些特定于应用程序的东西)。通过拥有两个“描述”这个特定对象的接口,您可以使用这个类的实例,只要您使用一个列表(并且仅此),同样,您可以在需要这些验证器的地方使用它作为小部件验证器(并且仅此)。这类似于多重继承,但更灵活。

简而言之(还有一些其他的答案是从这个开始的)。 接口定义了契约及其类实现 .
从技术上讲,一个类可以同时做这两件事,即,您不需要有接口,但对于大多数可能由几个类实现的任何行为(无论是与“模拟类”几乎相同的多个实现,还是V)定义API都是非常可取的。不同的类,但提供一个特定的通用服务/功能,如两个非常不同的列表。)

因为接口是契约,类是实现契约的方法。基于上下文可以有许多不同的方法来实现契约,因此将契约作为接口更有意义。可以有不同的实现