为什么大多数系统架构师坚持首先编程到接口？ [英] Why do most system architects insist on first programming to an interface?

问题描述

我读到的几乎所有的Java书都谈到使用接口作为在第一个构造似乎没有共享关系的对象之间共享状态和行为的一种方式。但是，每当我看到建筑师设计一个应用程序时，他们首先要做的就是开始编程接口。怎么来的？你如何知道那个接口内会发生的对象之间的所有关系？如果您已经知道这些关系，那么为什么不只是扩展一个抽象类？

解决方案

编程到界面意味着尊重合同通过使用该界面创建。因此，如果您的 IPoweredByMotor 接口具有 start（）方法，那么实现该接口的未来类将是 MotorizedWheelChair ， Automobile 或 SmoothieMaker ，在实施该方法界面，为您的系统增加灵活性，因为一段代码可以启动许多不同类型的动作，因为所有这一段代码需要知道的是他们回应 start（）。开始 并不重要，只是他们必须开始。

Almost every Java book I read talks about using the interface as a way to share state and behaviour between objects that when first "constructed" did not seem to share a relationship.

However, whenever I see architects design an application, the first thing they do is start programming to an interface. How come? How do you know all the relationships between objects that will occur within that interface? If you already know those relationships, then why not just extend an abstract class?

解决方案

Programming to an interface means respecting the "contract" created by using that interface. And so if your IPoweredByMotor interface has a start() method, future classes that implement the interface, be they MotorizedWheelChair, Automobile, or SmoothieMaker, in implementing the methods of that interface, add flexibility to your system, because one piece of code can start the motor of many different types of things, because all that one piece of code needs to know is that they respond to start(). It doesn't matter how they start, just that they must start.

这篇关于为什么大多数系统架构师坚持首先编程到接口？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！