抽象工厂模式（Abstract Factory Pattern）

抽象工厂模式是创建型设计模式的高级形式，其核心目标是为创建一系列相关或相互依赖的对象提供一个统一接口，而无需指定它们的具体类。它如同现实中的 “家电品牌工厂”—— 海尔工厂（具体工厂）可生产海尔冰箱、海尔空调（同一产品族），美的工厂可生产美的冰箱、美的空调，客户端只需选择品牌（工厂），即可获得配套的家电产品，无需关心具体型号的生产细节。

一、抽象工厂模式核心概念（通用）

1. 定义

提供一个接口，用于创建一系列相关或相互依赖的对象，而无需指定它们具体的类。抽象工厂模式关注 “产品族” 的创建，而非单一产品。

2. 意图

  • 封装产品族的创建：确保同一工厂创建的产品彼此兼容（如海尔冰箱和海尔空调可协同工作，无需担心适配问题）。
  • 隔离具体类的实例化：客户端仅依赖抽象工厂和抽象产品，不直接接触具体类（如 “我要海尔家电”，无需知道海尔冰箱的具体型号）。
  • 支持产品族的切换：客户端通过更换具体工厂，可无缝切换整套产品族（如从 “海尔” 切换到 “美的”，获取全新配套产品）。
  • 约束产品组合：避免客户端错误组合不同产品族的产品（如不会出现 “海尔冰箱 + 美的空调” 的不兼容组合）。

3. 核心术语与角色

抽象工厂模式的核心是 “产品族” 和 “产品等级结构”，包含 4 个核心角色：

术语 / 角色定义 / 职责
产品族（Product Family）同一工厂生产的、功能相关联的一系列产品（如海尔家电族：海尔冰箱、海尔空调）。
产品等级结构（Product Hierarchy）同一类产品的不同实现（如冰箱等级结构：海尔冰箱、美的冰箱、格力冰箱）。
AbstractFactory（抽象工厂）声明创建产品族中所有产品的接口（如createRefrigerator()创建冰箱，createAirConditioner()创建空调）。
ConcreteFactory（具体工厂）实现抽象工厂接口，负责创建某一产品族的所有具体产品（如HaierFactory创建海尔冰箱和海尔空调）。
AbstractProduct（抽象产品）定义产品等级结构的接口（如Refrigerator接口定义冰箱的通用功能）。
ConcreteProduct（具体产品）实现抽象产品接口，属于特定产品族（如HaierRefrigerator是海尔产品族的冰箱）。

二、抽象工厂模式详细解析（以 “家电生产” 为例）

以 “家电生产系统” 为场景：系统需支持多个品牌（海尔、美的）的家电生产，每个品牌需生产冰箱和空调（产品族），且同一品牌的冰箱和空调需兼容（如共享智能控制协议）。若用工厂方法模式，需为每个品牌的每个产品创建工厂（海尔冰箱工厂、海尔空调工厂、美的冰箱工厂...），导致工厂泛滥；抽象工厂模式通过HaierFactory（生产海尔冰箱 + 空调）和MideaFactory（生产美的冰箱 + 空调），将产品族的创建逻辑集中，简化系统设计。

1. 结构

  1. 产品等级结构：

    • 冰箱等级结构：Refrigerator（抽象产品）→ HaierRefrigerator、MideaRefrigerator（具体产品）；
    • 空调等级结构：AirConditioner（抽象产品）→ HaierAirConditioner、MideaAirConditioner（具体产品）。

  2. 产品族：

    • 海尔产品族：HaierRefrigerator + HaierAirConditioner；
    • 美的产品族：MideaRefrigerator + MideaAirConditioner。

  3. 工厂：

    • ElectricalFactory（抽象工厂）：声明createRefrigerator()和createAirConditioner()；
    • HaierFactory、MideaFactory（具体工厂）：实现上述方法，创建对应产品族。

2. 类图（Mermaid）

classDiagram
    %% 抽象产品1：冰箱接口（冰箱等级结构）
    class Refrigerator {
        <<Interface>>
        +cool(): void  // 制冷功能
    }

    %% 抽象产品2：空调接口（空调等级结构）
    class AirConditioner {
        <<Interface>>
        +adjustTemperature(): void  // 调温功能
    }

    %% 具体产品1-1：海尔冰箱（海尔产品族）
    class HaierRefrigerator {
        +cool(): void
    }

    %% 具体产品1-2：美的冰箱（美的产品族）
    class MideaRefrigerator {
        +cool(): void
    }

    %% 具体产品2-1：海尔空调（海尔产品族）
    class HaierAirConditioner {
        +adjustTemperature(): void
    }

    %% 具体产品2-2：美的空调（美的产品族）
    class MideaAirConditioner {
        +adjustTemperature(): void
    }

    %% 抽象工厂：家电工厂接口
    class ElectricalFactory {
        <<Interface>>
        +createRefrigerator(): Refrigerator  // 创建冰箱
        +createAirConditioner(): AirConditioner  // 创建空调
    }

    %% 具体工厂1：海尔工厂（生产海尔产品族）
    class HaierFactory {
        +createRefrigerator(): Refrigerator
        +createAirConditioner(): AirConditioner
    }

    %% 具体工厂2：美的工厂（生产美的产品族）
    class MideaFactory {
        +createRefrigerator(): Refrigerator
        +createAirConditioner(): AirConditioner
    }

    %% 客户端
    class Client {
        +useAppliances(): void
    }

    %% 关系梳理
    Refrigerator <|-- HaierRefrigerator
    Refrigerator <|-- MideaRefrigerator
    AirConditioner <|-- HaierAirConditioner
    AirConditioner <|-- MideaAirConditioner

    ElectricalFactory <|-- HaierFactory
    ElectricalFactory <|-- MideaFactory

    HaierFactory --> HaierRefrigerator : 创建
    HaierFactory --> HaierAirConditioner : 创建
    MideaFactory --> MideaRefrigerator : 创建
    MideaFactory --> MideaAirConditioner : 创建

    Client --> ElectricalFactory : 依赖抽象工厂
    Client --> Refrigerator : 依赖抽象产品
    Client --> AirConditioner : 依赖抽象产品

3. 时序图（Mermaid）

以 “客户端通过海尔工厂创建并使用海尔家电产品族” 为例，展示交互流程：

sequenceDiagram
    participant Client（客户端）
    participant HaierFactory（具体工厂：海尔）
    participant HaierRefrigerator（海尔冰箱）
    participant HaierAirConditioner（海尔空调）
    participant ElectricalFactory（抽象工厂）
    participant Refrigerator（抽象冰箱）
    participant AirConditioner（抽象空调）

    %% 1. 客户端选择具体工厂（海尔工厂）
    Client->>HaierFactory: new HaierFactory()
    HaierFactory-->>Client: 返回HaierFactory实例

    %% 2. 创建产品族中的第一个产品（冰箱）
    Client->>ElectricalFactory: createRefrigerator()（多态调用海尔工厂）
    HaierFactory->>HaierRefrigerator: new HaierRefrigerator()
    HaierRefrigerator-->>HaierFactory: 返回海尔冰箱实例
    HaierFactory-->>Refrigerator: 返回冰箱实例（向上转型）
    Refrigerator-->>Client: 客户端获取抽象冰箱对象

    %% 3. 创建产品族中的第二个产品（空调）
    Client->>ElectricalFactory: createAirConditioner()（多态调用海尔工厂）
    HaierFactory->>HaierAirConditioner: new HaierAirConditioner()
    HaierAirConditioner-->>HaierFactory: 返回海尔空调实例
    HaierFactory-->>AirConditioner: 返回空调实例（向上转型）
    AirConditioner-->>Client: 客户端获取抽象空调对象

    %% 4. 使用产品族（保证兼容性）
    Client->>Refrigerator: cool()（调用海尔冰箱制冷）
    HaierRefrigerator-->>Client: 执行："海尔冰箱：快速制冷中..."

    Client->>AirConditioner: adjustTemperature()（调用海尔空调调温）
    HaierAirConditioner-->>Client: 执行："海尔空调：智能调温至26℃..."

4. 优点

  • 保证产品族兼容性：同一具体工厂创建的产品属于同一产品族，天然兼容（如海尔冰箱和空调可协同智能控制），避免客户端错误组合不同品牌产品。
  • 封装产品创建细节：客户端只需通过抽象工厂接口获取产品，无需知道具体产品的类名和创建过程（如 “要海尔冰箱” 只需调用createRefrigerator()）。
  • 支持产品族整体切换：更换具体工厂即可切换整套产品族（如从HaierFactory切换到MideaFactory，所有产品自动变为美的系列），符合 “开闭原则”。
  • 隔离具体类依赖：客户端仅依赖抽象工厂和抽象产品，降低与具体类的耦合（如后续替换海尔冰箱的实现类，客户端无需修改）。

5. 缺点

  • 扩展新产品困难：若需为产品族新增产品（如新增洗衣机），需修改抽象工厂接口（添加createWashingMachine()），所有具体工厂也需同步修改，违反 “开闭原则”。
  • 系统复杂度高：产品族和工厂的增多会导致类数量急剧增加（n 个产品族 ×m 个产品等级 → n×m 个具体产品 + n 个具体工厂），增加维护成本。
  • 抽象层次高：相比工厂方法模式，抽象工厂引入更多抽象概念（产品族、多个抽象产品），理解和设计难度更大。

三、Java 代码实现（家电生产示例）

1. 抽象产品（Refrigerator、AirConditioner）

定义产品等级结构的接口：

// 抽象产品1：冰箱接口
public interface Refrigerator {
    // 制冷功能
    void cool();
}

// 抽象产品2：空调接口
public interface AirConditioner {
    // 调温功能
    void adjustTemperature();
}

2. 具体产品（海尔、美的系列）

实现抽象产品，属于特定产品族：

// 具体产品1-1：海尔冰箱（海尔产品族）
public class HaierRefrigerator implements Refrigerator {
    @Override
    public void cool() {
        System.out.println("海尔冰箱：快速制冷，智能控温中...");
    }
}

// 具体产品1-2：美的冰箱（美的产品族）
public class MideaRefrigerator implements Refrigerator {
    @Override
    public void cool() {
        System.out.println("美的冰箱：节能制冷，鲜存食材中...");
    }
}

// 具体产品2-1：海尔空调（海尔产品族）
public class HaierAirConditioner implements AirConditioner {
    @Override
    public void adjustTemperature() {
        System.out.println("海尔空调：智能调节至26℃，无风感模式...");
    }
}

// 具体产品2-2：美的空调（美的产品族）
public class MideaAirConditioner implements AirConditioner {
    @Override
    public void adjustTemperature() {
        System.out.println("美的空调：快速降温至24℃，静音运行...");
    }
}

3. 抽象工厂（ElectricalFactory）

声明创建产品族中所有产品的接口：

// 抽象工厂：家电工厂接口
public interface ElectricalFactory {
    // 创建冰箱（属于产品族）
    Refrigerator createRefrigerator();

    // 创建空调（属于产品族）
    AirConditioner createAirConditioner();
}

4. 具体工厂（HaierFactory、MideaFactory）

实现抽象工厂，创建对应产品族：

// 具体工厂1：海尔工厂（生产海尔产品族）
public class HaierFactory implements ElectricalFactory {
    @Override
    public Refrigerator createRefrigerator() {
        return new HaierRefrigerator(); // 海尔冰箱
    }

    @Override
    public AirConditioner createAirConditioner() {
        return new HaierAirConditioner(); // 海尔空调
    }
}

// 具体工厂2：美的工厂（生产美的产品族）
public class MideaFactory implements ElectricalFactory {
    @Override
    public Refrigerator createRefrigerator() {
        return new MideaRefrigerator(); // 美的冰箱
    }

    @Override
    public AirConditioner createAirConditioner() {
        return new MideaAirConditioner(); // 美的空调
    }
}

5. 客户端（Client）

通过抽象工厂获取产品族并使用：

// 客户端：使用家电产品族
public class Client {
    public static void main(String[] args) {
        // 1. 选择产品族（可从配置文件或用户输入动态获取）
        ElectricalFactory factory = new HaierFactory(); // 海尔产品族
        // ElectricalFactory factory = new MideaFactory(); // 切换为美的产品族

        // 2. 获取产品族中的产品（通过抽象接口）
        Refrigerator fridge = factory.createRefrigerator();
        AirConditioner ac = factory.createAirConditioner();

        // 3. 使用产品（无需关心具体品牌）
        System.out.println("=== 使用家电 ===");
        fridge.cool();
        ac.adjustTemperature();
    }
}

6. 输出结果（使用 HaierFactory 时）

=== 使用家电 ===
海尔冰箱：快速制冷，智能控温中...
海尔空调：智能调节至26℃，无风感模式...

若切换为MideaFactory，输出结果为：

=== 使用家电 ===
美的冰箱：节能制冷，鲜存食材中...
美的空调：快速降温至24℃，静音运行...

四、适用环境

抽象工厂模式适用于以下场景，核心判断标准是 “系统需使用多个相关产品族，且产品族内的产品需协同工作”：

  1. 系统依赖于产品族的创建：如 UI 框架（不同主题的按钮、文本框、下拉框构成产品族，需保证风格一致）、智能家居系统（同一品牌的灯光、空调、窗帘构成产品族，需兼容通信协议）。
  2. 产品族需整体切换：系统需支持在不同产品族间动态切换（如从 “深色主题” 切换到 “浅色主题”，所有 UI 组件同步变化）。
  3. 避免产品的不兼容组合：需限制客户端只能使用同一产品族的产品（如不允许 “Windows 风格按钮 + Mac 风格文本框” 的混搭）。
  4. 隐藏产品创建细节：客户端无需知道具体产品的类名，只需通过工厂获取（如数据库访问框架，客户端无需知道MySQLConnection或OracleConnection的存在）。

五、模式分析

1. 核心本质

抽象工厂模式的本质是 “产品族的统一创建与管理”：

  • 产品族绑定：通过具体工厂将相关产品（如冰箱和空调）绑定为一个家族，确保兼容性；
  • 抽象隔离：客户端通过抽象工厂和抽象产品接口访问系统，与具体实现完全隔离；
  • 族级切换：支持以 “产品族” 为单位进行整体替换，无需修改客户端逻辑。

2. 与其他模式的区别

模式核心差异典型场景
抽象工厂模式创建产品族（多个相关产品），如 “海尔冰箱 + 海尔空调”家电品牌、UI 主题、数据库访问
工厂方法模式创建单一产品，如 “海尔冰箱”汽车生产、日志系统（单一产品类型）
简单工厂模式一个工厂创建所有产品（无产品族概念），如 “冰箱工厂生产所有品牌冰箱”产品类型少且稳定（如计算器）
建造者模式关注单一复杂产品的分步构建，如 “分步组装一台电脑”复杂对象构建（电脑、文档）

3. 关键设计原则

  • 依赖倒置原则：客户端依赖抽象工厂和抽象产品，不依赖具体类（如Client仅依赖ElectricalFactory和Refrigerator）。
  • 开闭原则（有限支持）：新增产品族（如格力工厂）只需新增具体工厂，无需修改抽象工厂（符合开闭）；但新增产品（如洗衣机）需修改抽象工厂（违反开闭）。
  • 单一职责原则：每个具体工厂只负责创建一个产品族的产品（如HaierFactory只生产海尔系列），职责清晰。

六、模式扩展

抽象工厂模式可通过以下方式扩展，平衡扩展性和复杂性：

1. 带默认实现的抽象工厂

抽象工厂提供部分产品的默认实现，具体工厂只需重写需要定制的产品方法（适用于产品族中多数产品通用的场景）：

// 带默认实现的抽象工厂
public abstract class AbstractElectricalFactory implements ElectricalFactory {
    // 默认实现：创建基础款冰箱
    @Override
    public Refrigerator createRefrigerator() {
        return new BasicRefrigerator();
    }

    // 抽象方法：空调必须由子类实现
    @Override
    public abstract AirConditioner createAirConditioner();
}

// 具体工厂只需实现抽象方法
public class HaierFactory extends AbstractElectricalFactory {
    @Override
    public AirConditioner createAirConditioner() {
        return new HaierAirConditioner(); // 仅定制空调
    }
    // 复用默认冰箱实现
}

2. 工厂方法与抽象工厂结合

当产品族需扩展新产品时，可在抽象工厂中通过工厂方法模式延迟新产品的创建，避免直接修改抽象接口：

// 抽象工厂：通过工厂方法扩展新产品
public interface ElectricalFactory {
    Refrigerator createRefrigerator();
    AirConditioner createAirConditioner();
    
    // 工厂方法：返回新产品的工厂（而非直接创建产品）
    WashingMachineFactory getWashingMachineFactory();
}

// 新产品的工厂接口（工厂方法模式）
public interface WashingMachineFactory {
    WashingMachine createWashingMachine();
}

// 具体工厂实现
public class HaierFactory implements ElectricalFactory {
    @Override
    public WashingMachineFactory getWashingMachineFactory() {
        return new HaierWashingMachineFactory(); // 海尔洗衣机工厂
    }
    // ... 其他方法
}

3. 反射简化具体工厂

通过反射动态创建具体产品，减少具体工厂的代码量（适用于产品类名有规律的场景）：

// 通用具体工厂（通过反射创建产品）
public class GenericFactory implements ElectricalFactory {
    private Class<? extends Refrigerator> fridgeClass;
    private Class<? extends AirConditioner> acClass;

    // 构造器传入产品类
    public GenericFactory(Class<? extends Refrigerator> fridgeClass, 
                         Class<? extends AirConditioner> acClass) {
        this.fridgeClass = fridgeClass;
        this.acClass = acClass;
    }

    @Override
    public Refrigerator createRefrigerator() {
        try {
            return fridgeClass.newInstance(); // 反射创建
        } catch (Exception e) {
            throw new RuntimeException("创建冰箱失败");
        }
    }

    @Override
    public AirConditioner createAirConditioner() {
        try {
            return acClass.newInstance(); // 反射创建
        } catch (Exception e) {
            throw new RuntimeException("创建空调失败");
        }
    }
}

// 客户端使用：无需为每个品牌创建工厂
ElectricalFactory haierFactory = new GenericFactory(HaierRefrigerator.class, HaierAirConditioner.class);

七、模式应用（通用 + Android）

1. 通用领域应用

  • 数据库访问框架：
    • 抽象工厂：DBFactory（声明createConnection()、createStatement()）；
    • 具体工厂：MySQLFactory、OracleFactory；
    • 产品族：MySQLConnection+MySQLStatement、OracleConnection+OracleStatement；
    • 作用：保证同一数据库的连接和语句对象兼容。
  • UI 组件库（如 Swing）：
    • 抽象工厂：LookAndFeel（声明创建按钮、文本框等方法）；
    • 具体工厂：WindowsLookAndFeel、MacLookAndFeel；
    • 产品族：Windows 风格按钮 + 文本框、Mac 风格按钮 + 文本框；
    • 作用：确保 UI 组件风格统一。
  • 日志框架：
    • 抽象工厂：LogFactory（声明createFileLogger()、createConsoleLogger()）；
    • 具体工厂：Log4jFactory、Slf4jFactory；
    • 产品族：Log4j 的文件日志 + 控制台日志；
    • 作用：保证同一日志框架的组件协同工作。

2. Android 中的应用

Android 框架中，抽象工厂模式主要用于创建关联的系统组件或主题相关的 UI 元素：

（1）LayoutInflater 与视图工厂（ViewFactory）

  • 角色对应：

    • 抽象工厂：LayoutInflater.Factory（声明onCreateView()创建视图）；
    • 具体工厂：AppCompatViewInflater（创建兼容不同版本的视图）；
    • 产品族：同一主题的TextView、Button、ImageView（保证风格一致）；

  • 核心逻辑：

    // 自定义视图工厂（具体工厂）
public class CustomViewFactory implements LayoutInflater.Factory {
    @Override
    public View onCreateView(String name, Context context, AttributeSet attrs) {
        // 创建同一风格的视图（产品族）
        if ("Button".equals(name)) {
            return new CustomButton(context, attrs); // 自定义按钮
        } else if ("TextView".equals(name)) {
            return new CustomTextView(context, attrs); // 自定义文本框
        }
        return null;
    }
}

// 客户端使用工厂创建统一风格的视图
LayoutInflater inflater = LayoutInflater.from(context);
inflater.setFactory(new CustomViewFactory()); // 设置具体工厂
View view = inflater.inflate(R.layout.activity_main, null); // 创建产品族

（2）MediaPlayerFactory（媒体播放器工厂）

  • 角色对应：
    • 抽象工厂：MediaPlayerFactory（声明创建MediaPlayer、AudioTrack等方法）；
    • 具体工厂：DefaultMediaPlayerFactory、ExoPlayerFactory；
    • 产品族：默认播放器 + 默认音频轨道、Exo 播放器 + Exo 音频轨道；
  • 作用：确保媒体播放相关组件（播放器、轨道、解码器）彼此兼容。

（3）动画框架（AnimatorInflater）

  • 角色对应：
    • 抽象工厂：AnimatorInflater（声明创建ValueAnimator、ObjectAnimator等方法）；
    • 具体工厂：框架内部实现的动画工厂；
    • 产品族：同一动画系统的ValueAnimator+TimeInterpolator（插值器）；
  • 作用：保证动画相关组件协同工作，避免插值器与动画不兼容。

（4）通知管理器（NotificationManager）

  • 角色对应：
    • 抽象工厂：NotificationManager（声明创建Notification、NotificationChannel等方法）；
    • 具体工厂：不同 Android 版本的通知工厂实现；
    • 产品族：同一版本的通知 + 通知渠道 + 通知样式；
  • 作用：确保通知相关组件符合当前系统版本的规范。

八、总结

抽象工厂模式是 “产品族创建” 的核心解决方案，其核心价值在于 “统一管理相关产品、保证族内兼容性、支持整体切换”：

  1. 核心优势：完美解决产品族的协同创建问题，确保同一族产品兼容；客户端与具体实现解耦，支持产品族的整体替换；符合 “依赖倒置原则”，提高系统灵活性。
  2. 适用场景：系统需使用多个相关产品族、产品族需整体切换、需避免产品不兼容组合的场景（如 UI 主题、数据库访问、智能家居）。
  3. 实践建议：
    • 产品族稳定时使用抽象工厂，产品族频繁新增产品时需谨慎（扩展困难）；
    • 结合工厂方法模式处理产品扩展（如通过工厂方法延迟新产品创建）；
    • 简单场景可使用反射简化具体工厂代码，减少类数量；
    • 避免过度设计：若无需产品族概念，用工厂方法或简单工厂更合适。

抽象工厂模式不仅是一种创建对象的技巧，更是一种 “系统化管理关联对象” 的思维 —— 通过抽象工厂将相关产品组织成族，实现 “一站式获取” 和 “整体切换”，是构建复杂系统和框架的重要工具。

问题

工厂方法中具体产品的特有方法在业务中使用了 如果需要更换的新产品中不需要这个特殊的方法 是不是需要更改业务逻辑？

一、问题的核心原因

工厂方法模式的核心是通过抽象工厂和抽象产品，隔离客户端与具体产品的依赖。客户端应仅通过抽象产品的接口调用方法，而不直接依赖具体产品的特有方法。

如果业务逻辑中直接调用了具体产品的特有方法，说明：

  • 客户端依赖了具体产品（违反 “依赖倒置原则”）；
  • 抽象产品的接口设计不完整（未覆盖客户端所需的所有行为）。

此时更换新产品（且无该特有方法），业务逻辑必然会因 “方法不存在” 而报错，必须修改业务逻辑才能适配。

二、如何避免修改业务逻辑？

要解决这个问题，需从设计层面优化，确保客户端仅依赖抽象：

  1. 抽象产品接口的完善 将具体产品的特有方法提升至抽象产品接口中，作为所有产品的通用行为声明。

    • 若新产品 “不需要” 该方法，可在新产品中实现为空（或抛出不支持的异常），但需确保接口的一致性。

    • 示例：

      // 抽象产品
public interface Product {
    void commonMethod(); // 所有产品的通用方法
    void specialMethod(); // 原具体产品的特有方法，提升为抽象接口
}

// 旧产品（有特有方法）
public class OldProduct implements Product {
    public void commonMethod() { ... }
    public void specialMethod() { ... } // 实现特有逻辑
}

// 新产品（不需要特有方法）
public class NewProduct implements Product {
    public void commonMethod() { ... }
    public void specialMethod() { 
        // 空实现或抛出异常，避免客户端报错
        throw new UnsupportedOperationException("不支持该方法");
    }
}

  2. 使用接口隔离原则 若不同产品的行为差异过大，可拆分多个细分抽象接口，客户端仅依赖所需的接口。

    • 示例：

      // 基础接口（所有产品都支持）
public interface BaseProduct {
    void commonMethod();
}

// 特有行为接口（仅部分产品支持）
public interface SpecialProduct extends BaseProduct {
    void specialMethod();
}

// 旧产品实现特有接口
public class OldProduct implements SpecialProduct { ... }

// 新产品仅实现基础接口
public class NewProduct implements BaseProduct { ... }

// 客户端调用时，根据需要判断是否支持特有方法
public class Client {
    public void doBusiness(BaseProduct product) {
        product.commonMethod();
        // 仅当产品支持特有接口时才调用
        if (product instanceof SpecialProduct) {
            ((SpecialProduct) product).specialMethod();
        }
    }
}

    此时更换新产品（仅实现BaseProduct），客户端通过instanceof判断可避免调用不存在的方法，无需修改业务逻辑。

三、总结

  • 若业务逻辑依赖具体产品的特有方法：更换无该方法的新产品时，必须修改业务逻辑，这是设计缺陷导致的必然结果。
  • 若遵循 “依赖抽象” 原则：通过完善抽象接口或接口隔离，客户端仅依赖抽象产品，即使更换新产品，也无需修改业务逻辑（只需确保新产品符合抽象接口规范）。

因此，合理的抽象设计是避免业务逻辑修改的关键，而直接依赖具体产品的特有方法会导致系统耦合度高、扩展性差。

最近更新：:
Contributors: 罗凯文, luokaiwen