我在这里和其他论坛中搜索过，但找不到好的答案.. 我知道扩展课程并不是最好的做法。我应该更多地使用接口。我的问题是，通常我开始创建接口，然后转到抽象类，因为总是有一些我想在超类上实现的功能，这样我就不必在每个子类中复制它。 例如，我有一个 Vehicle 类以及 Car 和 Bike 子类。很多功能都可以在 Vehicle 类上实现，例如 Move() 和 Stop()，那么保持架构清洁、避免代码重复和使用接口而不是继承的最佳实践是什么？ 非常感谢！
（如果你不知道我为什么要问这个，你可以阅读这篇有趣的文章：http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-toolbox.html）
【问题讨论】：
标签： oop inheritance architecture interface extend
继承允许代码重用和可替换性，但限制了多态性。组合允许代码重用但不允许可替代性。接口允许可替代性，但不允许代码重用。
决定使用继承、组合还是接口，归结为几个简单的原则：
在决定未来的可替代类是否难以从基类派生时可能需要判断。但是，当需要可替代性时，我倾向于认为方法 5 经常提供所有世界中最好的。它通常比单独使用接口便宜，并且比单独使用继承贵不了多少。如果将来需要可替换但不能从基类派生的类，则可能需要将代码转换为使用方法#5。从一开始就使用方法#5 可以避免以后重构代码。 （当然，如果永远不需要替换不能从基类派生的类，那么额外的成本——尽管可能很小——最终可能是不必要的。
【讨论】：
我认为，接口有时也是邪恶的。它们可以避免多重继承。
但是如果我们将接口与抽象类进行比较，那么抽象类总是比接口多。接口始终是类的某个方面——某种观点，而不是作为一个类的整体。
所以我认为您不应该避免继承并在任何地方使用 iterfaces —— 应该保持平衡。
【讨论】：
如果您牢记接口和类之间的根本区别，则可以更轻松地决定使用哪一个。不同之处在于接口仅代表所涉及对象之间的协议（通常是行为），而抽象类代表一些涉及某些部分（数据）的未完成构造。在汽车示例中，界面本质上是通用汽车的蓝图。抽象类就像预制的特定模型车身，需要用剩余零件填充才能获得最终产品。接口甚至不必使用 Java - 它不会改变任何东西 - 仍然是蓝图。
通常，您会在特定的实现框架中使用抽象类来为其消费者提供一些基本功能。如果您只是声明您从不使用抽象类来支持接口 - 从实际角度来看这是完全错误的。如果您需要 90% 的相同代码的相同接口的 10 个实现怎么办。复制代码 10 次？好的，也许你会在这里使用抽象类，但把接口放在它上面。但是，如果您从不打算将您的类层次结构提供给外部消费者，您为什么要这样做呢？ 我在非常广泛的意义上使用外部这个词 - 它可以是您项目或远程消费者中的不同包。
归根结底，其中许多都是偏好和个人经历，但我不同意大多数笼统的陈述，例如 extends is evil。我也不喜欢使用额外的类（接口或抽象），除非设计的特定部分需要。
只要我的两分钱。
【讨论】：
同意 tofutim - 在您当前的示例中，在 Vehicle 上移动和停止是合理的。
阅读了这篇文章 - 我认为它使用强大的语言来推动观点......记住 - 继承是帮助完成工作的工具。
但是，如果我们假设在这种情况下由于任何原因您不能/不会使用该工具，您可以首先将其分解为带有帮助对象和/或访问者的小界面...
例如 - 车辆类型包括潜艇、船、飞机、汽车和自行车。你可以把它分解成接口...... 可移动 + 前锋（） + 向后（） + 左（） + 右（）
IF 可浮动 + 码头（）
ISink() + 吹气（）
飞飞() +起飞（） + 土地（）
然后您的类可以聚合您刚刚定义的过多接口。
问题在于，您最终可能会在汽车/自行车类中为 IMoveable.Left() 和 IMoveable.Right() 复制一些代码。您可以将其分解为辅助方法并聚合辅助方法...但如果您按照其逻辑结论进行操作，您最终仍会将许多东西重构回基类。
继承和聚合是工具……它们都不是“邪恶的”。
希望对您有所帮助。
【讨论】：
继承（“扩展类”）对类设计有很大的限制，我不确定使用接口代替继承是否是最好的主意，因为它无法通过 DRY 测试。
如今，组合比继承更受青睐，因此您可以考虑这篇文章：Prefer composition over inheritance?
【讨论】：
不要相信你读到的所有内容
基本上，只有在创建非常小的类树时才使用“仅接口”策略，否则，我保证会很痛苦。假设你有一个人“类”（有eat() 和sleep），并且有两个子类，数学家（有doProblem()）和Engineer（buildSomething()），然后使用接口。如果你需要一个 Car 类，然后是 56 种类型的汽车，那么就使用继承。
恕我直言。
【讨论】：
有趣的问题。每个人都有不同的方法。但这一切都基于个人经验和选择。
通常，我从一个接口开始，然后让一个抽象类继承该接口。并在那里实现共同的行动，让其他人由继承这个类的人来实现。
根据经验，这很少有优势，
1.在函数调用过程中，您可以将元素作为接口类型或抽象类类型传递。
2.ID、Names等常用变量可以放在抽象类中。
3.易于维护。例如，如果您想实现一个新接口，那么只需在抽象中快速实现即可。
【讨论】：
您需要针对您的具体案例还是一般情况的答案？在您描述的情况下，使用 Abstract 类没有任何问题。当所有客户端都需要为 Move() 和 Stop() 实现完全相同的代码时，使用接口是没有意义的。
【讨论】：