如何设计赛事场景类图（class diagram）实现按起跑号排序起跑序列

现有两种方案的优劣对比 #

• 方案A的核心问题是违反**DRY（不要重复自己）**原则：raceStartNumber作为所有交通工具的公共属性，分散在三个类中重复定义，后续如果要修改起跑号的校验规则、字段格式，需要同步修改三个类的逻辑，维护成本高。同时获取全量参赛对象时需要分别查询三类交通工具的集合再做聚合，排序逻辑的实现复杂度更高。
• 方案B的核心问题是违反接口隔离原则和单一职责原则：把不同交通工具的特有属性统一放到父类中，导致所有子类都会存在大量和自身无关的空置属性，后续如果新增摩托、电动滑板等新的交通工具类型，还要不断往父类累加属性，代码可扩展性极差。
• 两者相比方案A相对更合理，但都不是最优解。

更合理的实现方案 #

核心思路是抽离公共属性到抽象父类，通过继承实现能力复用，完全规避两类方案的缺陷：

1. 定义抽象父类 Vehicle（交通工具），所有交通工具共有的raceStartNumber属性、对应的取值/校验方法都在这个父类中实现，不需要重复定义。
2. 每个具体交通工具类继承Vehicle，仅定义自身特有的属性：
   • Car 类新增生产年份、型号属性
   • Bike 类新增型号、轮径属性
   • HorseCarriage 类新增马匹数量属性
3. Race 类中维护一个类型为 List<Vehicle> 的参赛交通工具集合，需要获取排序后的起跑序列时，直接对该集合按照raceStartNumber字段排序即可，不需要跨多个集合聚合，也没有冗余空置属性。

这个方案完全符合面向对象设计的开闭原则：后续新增其他交通工具类型时，只需要新增继承自Vehicle的子类即可，不需要修改现有类的逻辑，排序逻辑也可以完全复用。

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