我有一个抽象类Employee，它实现了接口IEmployee，并进一步由EmploymentType等抽象类组成。我使用了Abstract 类，以避免子类之间的通用功能代码重复。
所以我想问以下问题：
Interfaces 是否比 Abstract 更适合大型项目的课程？我问这个的原因是因为我看到很多企业应用程序使用接口比抽象类更多。这给人的印象是使用接口是构建企业应用程序的正确方法。【问题讨论】：
标签： java oop interface abstract-class
在您的基本抽象 Employee 类中存在哪些通用逻辑？我想说任何共享逻辑可能都是微不足道的，并且可能只是在后代之间复制（DRY 不一定总是要走的路）。这样，您可以只拥有一个 Employee 接口和一个或多个直接的具体祖先，在构造函数、getter 和 setter 中有一些重复的代码。这可以说是有争议的，但我已经多次看到这种方法更受欢迎。
EmploymentType 和 WorkLocation 可以是枚举而不是类，以避免任意字符串字段。也许 WorkTime 也可以是一个枚举；我在你的 UML 中看不到它的结构。 hourlyPay 字段可以封装在其中一种枚举类型中；根据您提供的信息，我不确定它最适合放在哪里。
关于接口的一般问题，请参阅 Joshua Bloch 撰写的 Effective Java，第 18 条（“首选接口而不是抽象类”）。还有“更喜欢组合而不是继承”的项目。从设计的角度来看，接口更简单、更灵活，并且因其可测试性而特别受欢迎。这是因为如果您有被声明为抽象类实例的协作者，那么它们可能包含难以测试的逻辑（例如初始化或附加依赖项）。声明为接口类型的协作者可以 100% 模拟。
【讨论】：
interface are flexible from a design standpoint 时，您是在谈论它们的实现还是多态性？另外，我考虑将方法从抽象类转移到接口的原因，所以我可以为我的类创建一个契约（按契约设计）。并在抽象类中实现这些方法以避免代码重复。