在Java城遭遇空前危机时，光靠Singleton侠一个人已经不够了。市民们需要：消防侠、闪电侠、盾甲侠、云原生侠……不同任务，需要不同英雄！

但问题来了：

“每次都要手动new一个英雄？代码里全是new FiremanHero()、new CloudNativeHero()？太乱了！”

这时，一位神秘科学家登场——Factory博士！

💬 “别再自己造英雄了！把需求告诉我，我来批量生产——而且保证类型正确、扩展无忧！”

---

🏭 一、简单工厂（Simple Factory）—— 英雄点餐机

市民对着机器喊：“我要消防侠！”
机器“哐当”一声，吐出一个 FiremanHero。

public class HeroFactory {
    public static Hero createHero(String type) {
        switch (type) {
            case "fire": return new FiremanHero();
            case "lightning": return new LightningHero();
            case "cloud": return new CloudNativeHero();
            default: throw new IllegalArgumentException("未知英雄类型！");
        }
    }
}

✅ 优点：使用简单，封装了创建逻辑。
❌ 缺点：每新增一个英雄，就要修改工厂代码！违反开闭原则！

漫画场景：Factory博士开着一个小摊，手写菜单，每次加新品都得重写黑板。

🏢 二、工厂方法模式（Factory Method）—— 英雄制造分部

为了解决扩展问题，Factory博士决定：建立连锁工厂！

• 消防局有自己的工厂 → 专门造消防侠
• 闪电联盟有自己的工厂 → 专门造闪电侠
• 云原生联盟也有自己的工厂 → 造云原生侠

// 抽象工厂接口
public interface HeroFactory {
    Hero createHero();
}

// 消防英雄工厂
public class FiremanHeroFactory implements HeroFactory {
    public Hero createHero() {
        return new FiremanHero();
    }
}

// 使用
HeroFactory factory = new CloudNativeHeroFactory();
Hero hero = factory.createHero(); // 自动产出云原生侠！

✅ 优点：新增英雄？只要新建一个工厂类，不用改原有代码！
✅ 符合 开闭原则：对扩展开放，对修改关闭。

漫画场景：Factory博士在全国开加盟店，每个分部只干一件事，专业又高效！

🌐 三、抽象工厂模式（Abstract Factory）—— 英雄套装生产线

某天，反派“耦合魔王”来袭，需要的不只是单个英雄，而是一整套 “云原生战队”：

• 云原生侠（Hero）
• 服务网格盾（Equipment）
• Prometheus眼（Sensor）

Factory博士升级技术，推出 “战队生成器”！

// 抽象工厂：能生产一整套装备
public interface CloudNativeTeamFactory {
    Hero createHero();
    Equipment createEquipment();
    Sensor createSensor();
}

// 具体工厂：K8s战队工厂
public class KubernetesTeamFactory implements CloudNativeTeamFactory {
    public Hero createHero() { return new CloudNativeHero(); }
    public Equipment createEquipment() { return new IstioShield(); }
    public Sensor createSensor() { return new PrometheusEye(); }
}

✅ 适用于 产品族（Product Family） 场景：多个相关对象需要一起创建。
❌ 缺点：新增一个产品（比如加个“AI助手”），所有工厂都要改！

漫画场景：Factory博士启动“英雄+装备+宠物”三位一体生产线，一键出战队！

🎯 工厂模式三兄弟对比表

模式	核心思想	适用场景	扩展性
简单工厂	一个工厂造所有英雄	英雄种类少、不常变	❌ 差
工厂方法	一个英雄一个工厂	英雄种类多、经常新增	✅ 好
抽象工厂	一个工厂造一整套战队	多个相关对象需配套使用	⚠️ 新增产品类型较难

💡 现实中的“英雄工厂”

• Spring 的 BeanFactory → 工厂方法
• JDBC 的 DriverManager → 简单工厂
• GUI 库（如 Swing）创建按钮、文本框 → 抽象工厂思想

---

🦸‍♀️ 下一期预告：观察者模式 —— Watcher女侠与“消息广播网”！

当Java城发生火灾、网络攻击、数据库崩溃……如何让所有关心的人立刻收到通知？
Watcher女侠将构建一个 “事件监听联盟”，实现 “一对多”的自动通知系统！