抽象类被描述为对一系列对象有用（例如，可用于哺乳动物）。但是，使用接口或抽象类来表示一系列相关对象有什么区别？
当我想定义通用功能时，我的流程是使用抽象类，但可以选择未来扩展和自定义功能（实现）的接口。
例如，我编写了一个抽象类来封装一些数据库功能，这些功能将在工作中的小型 Web 应用程序中大量使用。我编写了一个带有虚拟方法的抽象类，将来可以使用自定义功能（例如日志记录或可能需要的一些数据库事件报告）来覆盖它。
这是正确的方法吗？选择一种结构（抽象或接口）来代表一个家族有什么意义吗？
【问题讨论】：
标签： oop
当所有类型之间存在共同的状态和行为时，应该使用抽象类。当所有类型都有一个公共接口但不共享状态或行为时，应该使用接口。
这是一个例子。
德国牧羊犬、金毛猎犬、比格犬
这三个对象都是狗，因此它们具有某些共同的状态（肉食性、4 条腿等），并且它们还具有某些可覆盖的行为（吠叫、喘气等）。在这种情况下，创建一个抽象 Dog 类来保存这种常见的状态和行为并为每种类型的狗创建 Dog 的子类型是最有意义的。
铅笔、钢笔、粉笔
这些对象没有共同的状态，它们不能共享行为。然而你可能会注意到它们确实有一些共同点——它们都是写作的。这些对象最好单独构建，不使用基类，然后与公开每种类型的Write 方法的Writable 接口绑定在一起。
【讨论】：
我建议使用接口，以便您将来可以在数据库实用程序中实现新功能。
与往常一样，开发的主要设计原则是
设计面向接口，而不是实现
【讨论】：
使用抽象类，您可以提供层次结构中所有类都需要和共享的实现。因此，您正在重用代码。您可以允许派生类覆盖或不覆盖默认行为，但至少您提供了基线功能，例如为新生动物呼吸。但是，使用接口，您无法提供任何实现。您只需定义一个契约，所有继承该接口的类都应该遵守并为其提供实现。这可能会导致类的层次结构中出现重复和重复的代码。
接口的可扩展性不是很好，您需要担心版本控制。您决定对现有接口进行更改，但您很快就会意识到存在许多您可能需要修改的类。考虑将 Breath 方法添加到已经被许多哺乳动物使用的 IMammal 界面。您将需要为每个人提供 Breath 实施。使用抽象类，您可以简单地添加 Breath 方法并提供一些基线实现，而不必担心现有的派生类。因此抽象类在层次结构和 api 的开发方面更加灵活。
【讨论】：