除了开发人员之间的协调之外，是否有理由使用抽象或接口？

Question

  

可能重复：
  Interface vs Abstract Class (general OO)

我可以看到他们在协调开发团队或其他人可能进一步开发的代码方面的优势。

但如果没有，是否有理由使用它们？如果省略它们会发生什么？

摘要 - 我将能够实例化它。没问题。如果它没有意义 - 我不会。

接口 - 无论如何，我在从它派生的所有类中声明了该功能。

注意：我不问他们是什么。我问他们除了协调之外是否对它有帮助。

Answer 1

这两个都是我称之为合同的，可以由个别开发人员以下列方式使用：

摘要

• 允许不同派生实现的多态性。
• 允许用户创建基本功能，可以指明或不派生类需要实现。
• 如果派生未实现或需要实现，则允许默认操作为运行时消耗。
• 提供跨派生对象的一致性，基类指针可以使用它，而无需实际派生;因此，允许从基类引用对派生对象进行泛型操作，类似于运行时操作中的接口。

接口

• 允许使用通用模式作为事实contract of operation(s)。 这种用法可以针对手头的过程并允许 该合同的手术精确操作。
• 用于帮助 工厂模式（返回的对象），模拟数据期间 单元测试和替换现有类的能力（比如说 工厂返回接口）与不同的对象和它 由于接口合同的遵守，不会导致工厂的任何消费者重构的任何痛苦。
• 提供一种使用模式，可以很容易地从类的其余部分的静态中​​理解。

长话短说他们需要完成工作吗？没有。

但是如果你要设计的系统寿命超过一个周期，那么建筑师的前期工作无论是在团队还是个人身上都会得到回报。

---

++更新

我确实实践了我所宣传的内容，在将项目交给其他开发人员时，很高兴说

1. 查看所有主要业务类遵循的接口IProcess。该流程定义了一个目标系统，可以帮助您以定义的方式理解业务逻辑的目的和执行。
2. 在为项目维护和添加新功能的同时，接口实际上帮助我记住了流程，并轻松地将新的业务逻辑添加到项目中。

Answer 2

摘要 - 您可以实例化它的子项，但更重要的是，它可以有自己的非抽象方法和字段。

接口 - 关于抽象的更“粗略”，但在.NET中，您可以拥有多重继承。因此，通过定义接口，您可以引导接口的使用者订阅不同的合同（接口），从而呈现指定类型的不同“形状”。

Answer 3

我认为如果你没有与他人协调，它会做两件事

1. 有助于防止您对自己的代码执行奇怪的操作。想像 你写一个类，并在多个项目中使用它。你可能会进化 它在一个项目中，因此它无法识别它的堂兄 另一个项目。拥有抽象类或接口会让您受益 三思而后行改变功能签名。
2. 它为您提供了灵活性 - 这里有很多经典的例子。使用 你想要完成的东西的通用形式，如果 你决定以后需要一种不同的类型（streamreaders是一个 很好的例子，对吧？）你以后可以更轻松地实现它。

Answer 4

即使您没有与任何人协调，也有很多理由使用这两种构造。主要用途是实际上帮助表达开发者意图，这可能会帮助您稍后找出您选择实际选择的设计的原因。它们还可以允许进一步扩展性。

Abstract类允许您定义一个在多个派生类之间共享的公共实现，同时将一些行为委托给子类。它允许DRY（不要重复自己）原则，以避免在任何地方重复相同的代码。

接口表示您的类实现了一个特定的合同。这在框架内有非常有用的用途，其中包括：

• 使用需要实现某些接口的库功能。例如IDisposable，IEquatable，IEnumerable ......

• 在泛型中使用约束。

• 允许模拟接口（如果进行单元测试），而不必实例化真实对象。

• 使用COM对象