抽象类被描述为可用于一系列对象（例如可用于哺乳动物的动物）。然而，使用接口或抽象类来表示一系列相关对象之间有什么不同？抽象类与代表族的接口
我的过程是在我想定义常用功能但使用未来扩展选项和自定义功能（实现）接口时使用抽象类。
例如，我编写了一个抽象类来封装一些数据库功能，这些功能将大量用于工作中的小型Web应用程序。我用虚拟方法编写了一个抽象类，它可以在未来使用自定义功能（例如，日志记录或可能需要的某些数据库事件报告）进行覆盖。
这是正确的路吗？选择一个构造（抽象或界面）来表示一个家庭是否有任何意义？
当所有类型之间存在共同的状态和行为时，应该使用抽象类。当所有类型都具有通用接口但不共享状态或行为时应该使用接口。
这里是一个例子。
德国牧羊犬，金毛寻回犬，比格犬
这三个对象是所有的狗，因此他们某些共同的状态（食肉，4个腿等），他们也分享一定的可重复的行为（树皮，裤子等）。在这种情况下，最有意义的是创建一个抽象的Dog类来保存这种常见的状态和行为，并为每种类型的狗创建Dog的子类型。
铅笔，钢笔，粉笔
这些对象有没有共同的状态，它们不能共享行为。然而你可能会注意到他们有一些共同之处 - 他们是的作者。这些对象最好单独构建，并且没有基类，然后将其与Writable接口绑定在一起，从而暴露每种类型的Write方法。
非常符合我的决定。但我认为它们都适合代表家庭，只要我遵守你提供的指导方针。 – dotnetdev 2009-04-25 15:33:37
我会建议使用接口，以便您可以在将来的某个点上在数据库实用程序中实现新功能。
与往常一样，主要的设计原则，当谈到发展
对接口设计，而不是实现
抽象类，你可以提供一个由所有需要和共同实施层次结构中的类。因此，您正在重新使用代码。您可以允许派生类重写默认行为或不重复，但至少您可以为新生动物提供呼吸等基线功能。但是，使用接口，您不能提供任何实现。您只需定义一个合同，即所有继承该接口的类都应该遵守并提供实现。这可能会导致类层次结构中重复和重复的代码。
接口对于可扩展性不是很好，您需要担心版本控制。您决定对现有界面进行更改，但您很快就会意识到存在许多可能需要修改的类。考虑将呼吸方法添加到已被许多哺乳动物使用的IMammal界面。你需要去为每个人提供呼吸实施。通过抽象类，您可以简单地添加Breath方法并提供一些基准实现，而不必担心现有的派生类。所以抽象类在层次结构和API的开发方面更加灵活。
是否http://stackoverflow.com/questions/56867/interface-vs-base-class回答这个问题？如果是的话。 – Gishu 2009-04-25 15:35:04
可能重复[何时使用接口而不是抽象类，反之亦然？]（http://stackoverflow.com/questions/479142/when-to-use-an-interface-instead-of-an-abstract -class-反之亦然） – nawfal 2014-07-07 10:21:54