使用装饰器模式时为接口新增方法是否属于不当使用？

核心原因 #

• 违反开闭原则：面向对象设计的核心原则之一要求「对扩展开放，对修改关闭」，修改已稳定的主接口会波及所有已实现该接口的类。你示例中原有CarFrame、所有已存在的CarDecorator实现类都必须强制实现新增的getAquaticSpeed()、getColor()方法，哪怕普通陆地行驶的车辆根本不需要水上速度属性，只能返回无效值或抛出异常，完全不符合逻辑。
• 违反接口隔离原则：接口应当尽可能精简，只提供调用方必须的方法。强制给所有Car实现类增加不需要的水陆相关方法，会导致接口变得臃肿，后续维护成本直线上升。
• 违背装饰器模式的设计初衷：装饰器存在的核心价值就是在不修改原有接口、不改变原有类继承结构的前提下，给对象动态附加功能。你直接修改主接口的做法完全抵消了装饰器的优势，属于典型的误用。

正确实现思路 #

你可以根据业务场景二选一：

1. 扩展子接口而非修改父接口
   如果水陆两栖是一类特殊Car的通用能力，可以定义新的子接口继承原有Car接口，装饰器实现该子接口即可，完全不影响原有逻辑：

// 原有Car接口保持不变
interface Car{
   public float getSpeed();
}

// 新增子接口
interface AmphibiousCar extends Car {
    public float getAquaticSpeed();
}

// 两栖装饰器实现子接口
public class AmphibiousCarDecorator extends CarDecorator implements AmphibiousCar {
    public AmphibiousCarDecorator(Car delegate) {
        super(delegate);
    }

    @Override
    public float getSpeed() {
        // 陆地速度逻辑
        return super.getSpeed();
    }

    @Override
    public float getAquaticSpeed() {
        // 水上速度逻辑
        return 30f;
    }
}

2. 装饰器内部持有扩展属性
   如果只是给部分Car实例动态附加颜色、水上速度这类可选属性，不需要让所有Car都具备对应能力，直接在装饰器类内部定义属性和方法即可，不需要修改上层接口。

例外情况 #

如果你的Car接口仍处于业务迭代早期，还没有大量的第三方实现类，且业务确实要求所有Car类型都必须具备颜色属性，直接修改接口也并非完全不可行，但这种场景下你其实不需要用装饰器来做扩展，直接修改所有实现类即可。 #

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