本文介绍在 java 中通过组合（composition）替代多重继承或代码复制，解决具有交叉共性行为的类建模问题，兼顾可扩展性、低耦合与多态支持。
本文介绍在 java 中通过组合（composition）替代多重继承或代码复制，解决具有交叉共性行为的类建模问题，兼顾可扩展性、低耦合与多态支持。
在面向对象设计中，当多个子类需共享部分而非全部行为（例如 BikeStation 和 CanoeStation 各有专属逻辑，而 BikeAndCanoeStation 需同时具备二者能力），强行采用单一继承链会导致重复代码、违反 DRY 原则，且难以应对未来新增类型（如 E-ScooterStation）。此时，组合优于继承（Favor Composition Over Inheritance） 是更符合开闭原则与单一职责原则的解决方案。
核心思路是：将共性行为封装为独立的、可复用的组件（Component），让宿主类（如 BikeAndCanoeStation）通过持有这些组件实例并委托调用，实现功能拼装。同时，结合接口定义契约，保障多态统一性与编译期类型安全。
✅ 推荐实践：接口 + 组合 + 委托
首先，为不同行为域定义清晰接口：
public interface BikeCapable {
void borrowBike();
void returnBike();
int getAvailableBikes();
}
public interface CanoeCapable {
void borrowCanoe();
void returnCanoe();
int getAvailableCanoes();
}接着，实现具体行为组件（非 Station 子类，而是独立职责类）：
public class BikeService implements BikeCapable {
private int availableBikes = 10;
@Override
public void borrowBike() {
if (availableBikes > 0) availableBikes--;
}
@Override
public void returnBike() {
availableBikes++;
}
@Override
public int getAvailableBikes() {
return availableBikes;
}
}
public class CanoeService implements CanoeCapable {
private int availableCanoes = 5;
@Override
public void borrowCanoe() {
if (availableCanoes > 0) availableCanoes--;
}
@Override
public void returnCanoe() {
availableCanoes++;
}
@Override
public int getAvailableCanoes() {
return availableCanoes;
}
}然后，重构 Station 层级结构：抽象基类聚焦真正通用属性（如位置、名称、运营状态），并将多态入口方法声明为抽象或默认实现：
public abstract class Station {
protected final String name;
protected final String location;
public Station(String name, String location) {
this.name = name;
this.location = location;
}
// 真正通用的方法（如打印信息、校验状态）
public void printInfo() {
System.out.printf("Station: %s (%s)%n", name, location);
}
// 多态核心：由子类决定“如何提供服务”
public abstract void provideService();
}最后，各具体站点类通过组合复用组件，并实现多态协议：
public class BikeStation extends Station implements BikeCapable {
private final BikeService bikeService = new BikeService();
public BikeStation(String name, String location) {
super(name, location);
}
@Override
public void provideService() {
System.out.println("Providing BIKE service...");
borrowBike(); // delegation
}
// 委托至 BikeService
@Override
public void borrowBike() { bikeService.borrowBike(); }
@Override
public void returnBike() { bikeService.returnBike(); }
@Override
public int getAvailableBikes() { return bikeService.getAvailableBikes(); }
}
public class CanoeStation extends Station implements CanoeCapable {
private final CanoeService canoeService = new CanoeService();
public CanoeStation(String name, String location) {
super(name, location);
}
@Override
public void provideService() {
System.out.println("Providing CANOE service...");
borrowCanoe();
}
@Override
public void borrowCanoe() { canoeService.borrowCanoe(); }
@Override
public void returnCanoe() { canoeService.returnCanoe(); }
@Override
public int getAvailableCanoes() { return canoeService.getAvailableCanoes(); }
}
// ✅ 关键：BikeAndCanoeStation 同时组合两种能力，无代码复制
public class BikeAndCanoeStation extends Station implements BikeCapable, CanoeCapable {
private final BikeService bikeService = new BikeService();
private final CanoeService canoeService = new CanoeService();
public BikeAndCanoeStation(String name, String location) {
super(name, location);
}
@Override
public void provideService() {
System.out.println("Providing BIKE & CANOE service...");
borrowBike();
borrowCanoe();
}
// 全部委托，逻辑复用零冗余
@Override
public void borrowBike() { bikeService.borrowBike(); }
@Override
public void returnBike() { bikeService.returnBike(); }
@Override
public int getAvailableBikes() { return bikeService.getAvailableBikes(); }
@Override
public void borrowCanoe() { canoeService.borrowCanoe(); }
@Override
public void returnCanoe() { canoeService.returnCanoe(); }
@Override
public int getAvailableCanoes() { return canoeService.getAvailableCanoes(); }
}✅ 使用示例与多态验证
public class StationDemo {
public static void main(String[] args) {
List<Station> stations = Arrays.asList(
new BikeStation("Central Bike Hub", "Downtown"),
new CanoeStation("River Launch", "Riverside"),
new BikeAndCanoeStation("Hybrid Dock", "Harbor")
);
// 多态调用 —— 统一接口，不同行为
for (Station station : stations) {
station.printInfo();
station.provideService(); // 运行时动态绑定
}
// 类型安全的扩展操作（利用接口）
if (stations.get(2) instanceof BikeCapable bikeCapable) {
bikeCapable.borrowBike();
}
}
}⚠️ 注意事项与最佳实践
- 避免“组合爆炸”：若组件间存在强依赖或协同逻辑（如借车后需同步更新总库存），可引入协调器（Coordinator）或事件机制，而非在宿主类中硬编码耦合逻辑。
- 接口粒度要合理：按业务能力（Capability）而非技术实现划分接口（如 BikeCapable 而非 BikeOperationInterface），提升语义清晰度与复用率。
- 构造注入优于 setter 注入：示例中使用 final 组件字段 + 构造器初始化，确保不可变性与线程安全基础。
- 警惕过度设计：若仅有两个类且行为差异极小，简单继承仍可接受；组合的价值在 3+ 类型、2+ 交叉维度、高频迭代 场景下才显著凸显。
- 与策略模式互补：当某类行为需运行时切换（如支付方式），可在组件层引入策略；此处为静态能力装配，组合已足够。
通过组合模式，我们不仅消除了重复代码，更实现了高内聚、低耦合的设计目标：每个组件专注单一职责，宿主类专注组装逻辑，新站点类型只需组合已有能力或扩展新接口，系统演进成本大幅降低——这才是面向对象设计的本意。
