新员工对象设计疑问：空Internal类继承抽象Employee是否合理

结论 #

保留无额外属性的Internal子类是更合理的设计，不要直接用抽象父类Employee指代内部员工。

核心原因 #

• 避免逻辑判断的隐性缺陷
  若直接用Employee作为内部员工的实现类，后续做类型区分时只能通过反向判断if (!(employee instanceof Outsourced))实现，未来新增第三方派驻、实习员工等其他员工类型时，这部分判断逻辑会全部失效，需要全量排查修改。而保留Internal类后，可以直接通过employee instanceof Internal做正向判断，逻辑清晰且兼容性更强。
• 预留无成本的扩展空间
  现阶段Internal没有专属属性不代表后续不会新增，内部员工常见的工号、所属部门、职级、入职日期等属性都属于和外包员工差异化的字段，后续有需求时直接在Internal类中添加即可，完全不会影响父类和其他子类的逻辑。如果用Employee指代内部员工，后续新增内部专属属性时只能加到父类中，会导致外包等其他子类继承到无关属性，违反类设计的单一职责原则。
• 符合面向对象的语义规范
  抽象类Employee的定位是所有员工的公共属性/方法聚合，本身不应该对应具体的业务实体，Internal和Outsourced作为两个具体的员工实体子类，在语义上完全对等，后续维护代码的开发人员可以快速理解类的分层逻辑，不会出现“抽象父类同时承载具体业务实现”的歧义。

如果确实介意空类的设计，也可以在Internal中添加必要的构造方法，和Outsourced的构造方法做统一对齐，或者根据业务需要在父类Employee中定义抽象方法，两个子类分别做实现，进一步强化子类的存在意义。

内容的提问来源于stack exchange，提问作者Jonathan Cabral