五种创建型模式协作实战：从类爆炸到冗余消除

1. 项目概述：从“五模式堆满”到“冗余清零”

接手一个RPG游戏原型项目时，我给自己的目标是写一个能同时展示五种创建型模式的完整实例。结果第一版代码一写完，自己都看不下去——类文件堆了近30个，大量重复的取配置逻辑散落在各个工厂里，建造者里每个setter都是同样的校验三件套，原型模板的获取方式五花八门。与其说这是“用全创建型模式”，不如说是把GoF教材按目录抄了一遍。后来我花了三个晚上做重构，核心思路就是标题里这四个字：冗余消除。

这篇文章不打算讲创建型模式的教科书定义，那些随便搜一下就有。我想分享的是：一个真实实例里，单例、工厂方法、抽象工厂、建造者、原型这五种模式同时出现时，哪些代码其实是在重复造轮子，怎么用“模式协作”的思路把这些冗余压到最低，并且保证重构前后行为完全一致。适合正在学设计模式、又不想停留在概念阶段的人，也适合在工作中被“类爆炸”困扰、想给代码做瘦身的同学。

先说结论：优化之后，类数量从29个降到17个，核心重复代码从约200行压到30行以内，五种模式一个都没有少，反而各自的边界更清楚了。下面我把完整过程拆开讲。

1.1 这个实例到底在做什么

整个实例的业务场景是一个简化版角色创建系统。它有五个核心能力：

• 全局配置管理：保存玩家等级、初始金币、经验倍率等运行期参数，这是全局唯一入口，天然适合单例模式。
• 角色装备生产：按职业（战士、法师、游侠）生成对应的武器、护甲、饰品，这是一族产品的创建，天然适合抽象工厂模式。
• 角色对象构建：角色是包含基础属性、技能列表、装备栏、称号等多个部件的复杂对象，分步组装的过程适合建造者模式。
• 角色模板克隆：系统预置了若干角色模板，创建新角色时基于模板复制一份再修改，适合原型模式。
• 敌人对象生成：根据关卡配置生成普通怪、精英怪、Boss，这是“由一个方法决定创建哪种对象”的经典场景，适合工厂方法模式。

如果只写“演示代码”，每种模式独立写一个Demo，那一点难度都没有。难点在于这五种模式要在一个系统里协同工作，而且不许有冗余。第一版的问题恰恰出在这里：每种模式单独看都“标准”，放在一起就互相重叠、互相抢活干。

1.2 为什么用“角色创建系统”承载五种创建型模式

选这个场景我其实踩过一个误区。一开始我想用“文档导出工具”做例子，做了一半发现，工厂方法和抽象工厂在里面几乎是硬凑的，五种模式之间没有调用关系，最后就成了五个互不相干的Demo拼盘。

后来换成角色创建系统，最大的变化是模式之间出现了真实的数据流：角色构建时，建造者需要从装备工厂拿装备，需要从配置中心读初始属性，需要从模板库克隆基础预设，而敌人工厂又需要读配置中心生成不同强度的敌人。数据流一出现，模式之间的协作就不可避免，冗余也就随之产生了。

所以选场景的原则很简单：不是找“能套五种模式”的场景，而是找“五种模式都有存在必要”的场景。角色创建系统刚好满足——对象构建复杂度够（建造者）、产品族够（抽象工厂）、产品变体够（工厂方法）、全局状态够（单例）、模板复制够（原型）。

1.3 优化核心：冗余消除不等于把模式删掉

很多人一听“冗余消除”，第一反应是把类合并、把工厂删掉、直接用new。这完全跑偏了。设计模式带来的间接性不是冗余，是应对变化的成本。真正冗余的是：同一个逻辑写了三遍、同一个职责有两条代码路径、同一个信息散落在多个类里。

我用三个标准来判断什么该消、什么该留：

• 不可替代的间接性要留。比如抽象工厂带来的“产品族可以整体替换”，这个间接层一旦删除，换一套产品族就要改调用方，这种冗余看似多余，实则是模式的灵魂，必须保留。
• 复制粘贴带来的冗余要消。比如三个职业工厂里有80行完全相同的等级换算逻辑，这只是因为没有提取公共父类，和模式本身无关。
• 职责重叠造成的冗余要消。比如建造者里校验了角色名，工厂里又校验了一遍角色名，这属于两个模式抢一份工作，必须划定边界。

明确了这三条，后面的重构方向就清楚了：每种模式保留它的核心机制，但把实现过程中产生的重复代码、重叠职责、混乱入口全部清理干净。

2. 第一版实现：堆砌模式后暴露的三类典型冗余

第一版代码我没有直接删掉，而是专门留着观察冗余发生的规律。后来发现，多模式并存时的冗余高度集中在三个地方：工厂子类里的初始化逻辑、建造者里的校验赋值、以及原型对象的获取与管理。这一节我把原始代码中的关键问题摘出来，指出它们“冗余在哪”。

2.1 第一版结构全景

第一版的类结构大致是这样：

code复制config/
  GameConfigManager        // 单例：静态字段+getInstance()
factory/
  EquipmentFactory         // 抽象工厂接口
  WarriorEquipmentFactory  // 战士装备工厂
  MageEquipmentFactory     // 法师装备工厂
  RangerEquipmentFactory   // 游侠装备工厂
  EnemyFactory             // 工厂方法：switch-case生成敌人
builder/
  HeroBuilder              // 建造者：大量重复校验
  Director                 // 导演：编排构建步骤
prototype/
  HeroTemplate             // 原型基类：提供clone()
  WarriorTemplateManager   // 战士模板管理器
  MageTemplateManager      // 法师模板管理器
model/
  Hero/Weapon/Armor/...    // 领域对象

表面上各模式的类都有，但问题很明显：每个职业工厂内部都有几乎一样的“读取配置→换算数值→创建对象”代码；每个模板管理器里都有一套独立的模板初始化流程；单例的访问有的用getInstance()，有的直接拿静态字段，还有的在工厂内部临时new出来再覆盖。类是多，但每多一个类，就多一份重复逻辑。

2.2 冗余点一：抽象工厂子类之间的大段复制

先看第一版里战士装备工厂的关键代码：

java复制public class WarriorEquipmentFactory implements EquipmentFactory {
    @Override
    public Weapon createWeapon() {
        Weapon weapon = new Weapon("warrior_sword");
        int playerLevel = GameConfigManager.getInstance().getPlayerLevel();
        weapon.setAttack(20 + playerLevel * 2);
        weapon.setLevelRequirement(levelRequirement);
        return weapon;
    }

    @Override
    public Armor createArmor() {
        Armor armor = new Armor("warrior_plate");
        int playerLevel = GameConfigManager.getInstance().getPlayerLevel();
        armor.setDefense(15 + playerLevel * 2);
        armor.setLevelRequirement(levelRequirement);
        return armor;
    }
}

法师工厂和游侠工厂的代码几乎一模一样，区别只有武器名、基础攻击、基础防御这几个数字。20 + playerLevel * 2这种等级换算逻辑，三个工厂各写了一遍，总量加起来将近100行。这是典型的“面向复制粘贴编程”：如果以后数值公式调整，比如改成20 + playerLevel * 3 + levelRequirement / 2，就得改三个地方，漏改一个就是线上事故。

抽象工厂模式本身没有问题，“每个职业一族装备”这个设计是对的。问题在于实现时没有提炼“族与族之间的公共差异”，把相同的逻辑复制到了每个子类里。这是重构要消除的头号冗余。

2.3 冗余点二：建造者内部重复的校验与赋值

建造者模式的职责是分步组装复杂对象。但在第一版里，每个setter方法的骨架都长成一个样：

java复制public HeroBuilder name(String name) {
    if (name == null || name.trim().isEmpty()) {
        throw new IllegalArgumentException("名称不能为空");
    }
    if (name.length() > 12) {
        throw new IllegalArgumentException("名称长度不能超过12");
    }
    this.hero.setName(name);
    return this;
}

public HeroBuilder title(String title) {
    if (title == null || title.trim().isEmpty()) {
        throw new IllegalArgumentException("称号不能为空");
    }
    if (title.length() > 20) {
        throw new IllegalArgumentException("称号长度不能超过20");
    }
    this.hero.setTitle(title);
    return this;
}

HeroBuilder里一共有六个这样的setter，每个都有“非空校验+长度校验+设置值+返回this”四步。六段代码长得一模一样，只有字段名和长度上限不同。更麻烦的是，Director在构建角色时，构建流程里还重复做了一次参数检查，等于校验逻辑分散在两个类里。

这里的问题不是建造者模式错了，而是“校验-赋值”这种横切逻辑没有收敛。第一版的建造者把业务规则写进了每个方法体，职责边界不清晰，后续加字段就得再复制一遍。

2.4 冗余点三：原型获取方式混乱，工厂职责被架空

原型模式在第一版里的实现最乱。我定义了一个HeroTemplate基类和两个模板管理器：

java复制public class WarriorTemplateManager {
    private static HeroTemplate warriorTemplate;

    public static Hero getWarriorTemplate() {
        if (warriorTemplate == null) {
            warriorTemplate = new HeroTemplate();
            warriorTemplate.setName("战士默认模板");
            warriorTemplate.setHp(100);
            warriorTemplate.setMp(30);
            // 后半段初始化省略...
        }
        return warriorTemplate.copy();
    }
}

法师也有一套几乎相同的代码，名称、属性不同而已。这个实现的问题是：

• 模板获取入口不统一。有的地方调WarriorTemplateManager.getWarriorTemplate()，有的地方直接new一个HeroTemplate再手动set值，导致“从模板创建”和“从零创建”在调用方看来没有区别。
• 模板管理器之间没有公共抽象。每个管理器都自己管一个静态模板字段，初始化逻辑重复。
• 原型注册表缺失。GoF模式里原型通常配一个注册表（Registry），按key取模板克隆。第一版没有这个概念，每个模板类型对应一个Manager，本质上是把注册表拆碎了。

还有更隐蔽的问题：装备工厂里创建装备时，也顺便复制了一份角色模板的默认属性。原型模式和抽象工厂的职责在这里打架了——装备工厂本该只创建装备，却跑去初始化角色模板。这种职责重叠，同样是冗余。

3. 优化重构：让五种模式真正“协作”起来

第一版代码的问题摸清了，我开始第二轮重构。重构的目标很明确：保留五种创建型模式的核心机制，消灭实现过程中的重复代码和职责重叠。下面按重构顺序一步步拆解。

3.1 优化总原则：每个模式只做一件不可替代的事

动手之前，我先给五个模式划清了职责边界：

这个表格我贴在显示器上写完了所有重构代码。后面每动一处，都会问一句：这是不是越界了？越界就是冗余的温床。

3.2 抽象工厂泛型化，用枚举驱动消灭重复子类

第一版三个职业工厂的重复根源是：每个工厂内部都有“读配置→算数值→创建对象”的固定步骤，区别只是枚举值。那最简单的做法就是把这个固定步骤上移到抽象父类，让子类只负责提供一个类型枚举。

重构后的抽象工厂设计：

java复制public enum EquipmentType {
    WARRIOR("warrior_sword", "warrior_plate", 20, 15),
    MAGE("mage_staff", "mage_robe", 18, 12),
    RANGER("ranger_bow", "ranger_leather", 17, 14);

    private final String weaponName;
    private final String armorName;
    private final int weaponBaseAttack;
    private final int armorBaseDefense;
    // 构造器与getter省略...
}

java复制public abstract class AbstractEquipmentFactory {
    protected abstract EquipmentType getType();

    public Weapon createWeapon() {
        EquipmentType type = getType();
        Weapon weapon = new Weapon(type.getWeaponName());
        int playerLevel = GameConfigManager.INSTANCE.getPlayerLevel();
        weapon.setAttack(type.getWeaponBaseAttack() + playerLevel * 2);
        weapon.setLevelRequirement(levelRequirement);
        return weapon;
    }

    public Armor createArmor() {
        EquipmentType type = getType();
        Armor armor = new Armor(type.getArmorName());
        int playerLevel = GameConfigManager.INSTANCE.getPlayerLevel();
        armor.setDefense(type.getArmorBaseDefense() + playerLevel * 2);
        armor.setLevelRequirement(levelRequirement);
        return armor;
    }
}

java复制public class WarriorEquipmentFactory extends AbstractEquipmentFactory {
    @Override
    protected EquipmentType getType() {
        return EquipmentType.WARRIOR;
    }
}

这样战士、法师、游侠三个工厂类的代码彻底瘦身，每个类只剩三行。等级换算逻辑只存在于父类一处，改动一处所有职业同时生效。抽象工厂的“产品族可整体替换”能力依然保留——需要新增一个职业时，加一个枚举值+一个三行子类即可。

用生活类比解释这个改动：原来三个工人各带一套工具箱，里面锤子、螺丝刀、卷尺各买了一份，现在统一配了个工具房，谁干活谁去领同一套工具，节省的是三份工具钱，干活的人还是三个人。

3.3 建造者引入模板方法，校验逻辑上移

建造者的冗余集中在setter里的“非空+长度”校验。这类校验是横切逻辑，最适合用模板方法收敛。我在建造者内部提炼了一个公共的checkAndSet流程：

java复制public abstract class BaseHeroBuilder {
    protected final Hero hero = new Hero();

    protected void checkNotEmpty(String value, String fieldName, int maxLength) {
        if (value == null || value.trim().isEmpty()) {
            throw new IllegalArgumentException(fieldName + "不能为空");
        }
        if (value.length() > maxLength) {
            throw new IllegalArgumentException(fieldName + "长度不能超过" + maxLength + "个字符");
        }
    }

    public BaseHeroBuilder name(String name) {
        checkNotEmpty(name, "名称", 12);
        hero.setName(name);
        return this;
    }

    public BaseHeroBuilder title(String title) {
        checkNotEmpty(title, "称号", 20);
        hero.setTitle(title);
        return this;
    }

    // 其他属性setter同理...
    public abstract Hero build();
}

子类HeroBuilder继承BaseHeroBuilder，只需补充职业相关的特定逻辑（比如法师必须设置魔法值、游侠必须设置敏捷初始值），不再需要重写校验。新增字段时，公共校验逻辑一劳永逸。

这个改动的本质是：把建造者模式里“分步构建”的骨架保留住，把重复的横切逻辑上提到抽象基类。GoF里本来就提倡将不变的部分放在基类，变化的逻辑由子类实现，这正是模板方法思想和建造者模式的天然结合。

很多讲建造者模式的资料会强调Builder接口、ConcreteBuilder、Director三者关系，但很少提醒：多个Builder并存时，重复的校验逻辑如果不提取，代码量会成倍膨胀。这一条实战经验在这个例子里体现得淋漓尽致。

3.4 原型注册表：让克隆这件事有统一入口

原型模式最大的坑是“模板散落各处”。第一版每个类型一个Manager，导致调用方必须知道具体Manager类名，耦合严重。优化时我引入了原型注册表，用枚举管理所有模板，注册表内部持有原型实例，对外只暴露getTemplate方法。

java复制public enum HeroTemplateRegistry {
    INSTANCE;

    private final EnumMap<HeroTemplateKey, Hero> templates = new EnumMap<>(HeroTemplateKey.class);

    HeroTemplateRegistry() {
        initTemplates();
    }

    private void initTemplates() {
        templates.put(HeroTemplateKey.WARRIOR_DEFAULT, buildWarriorTemplate());
        templates.put(HeroTemplateKey.MAGE_DEFAULT, buildMageTemplate());
        templates.put(HeroTemplateKey.RANGER_DEFAULT, buildRangerTemplate());
    }

    private Hero buildWarriorTemplate() {
        Hero base = new Hero();
        base.setName("战士默认模板");
        base.setHp(100);
        base.setMp(30);
        base.setAttack(20);
        // 其他初始化...
        return base;
    }

    public Hero getTemplate(HeroTemplateKey key) {
        Hero template = templates.get(key);
        if (template == null) {
            throw new IllegalArgumentException("未知模板: " + key);
        }
        return template.copy();
    }
}

这个注册表的好处是：模板的创建、存储、克隆三个动作全部收敛到一个类里。业务方想拿到一个“战士默认模板”，只需要传一个枚举key，不需要感知内部到底存在哪、怎么建的。

原型模式在这里发挥作用的关键是：getTemplate返回的是template.copy()，而不是模板本身。这一点必须守住，否则调用方拿到同一个引用改来改去，模板库就被污染了。后面重构测试时，我就专门为这个写了一个“多次获取互不影响”的用例。

3.5 工厂方法用注册映射干掉switch-case

第一版的EnemyFactory是典型的switch-case工厂方法实现：

java复制public Creature createEnemy(EnemyType type) {
    switch (type) {
        case NORMAL:
            return new NormalCreature();
        case ELITE:
            return new EliteCreature();
        case BOSS:
            return new BossCreature();
        default:
            throw new IllegalArgumentException("未知敌人类型");
    }
}

这段代码看着简洁，实际扩展一次就要改一次createEnemy方法，违反开闭原则。优化前我数了一下，这个switch已经因为迭代改了四次，每次都在同一个方法里加case，整条方法越来越胖。

更关键的是，这个工厂方法和抽象工厂的职责边界乱掉了——EnemyFactory在创建精英怪时，还会自己调用WarriorEquipmentFactory给精英怪配装备。这就违反了我在3.1里定下的“工厂方法不负责产品族切换”原则。

重构后，敌人创建改用注册映射：

java复制public class CreatureFactory {
    private final Map<EnemyType, Supplier<Creature>> registry = new EnumMap<>(EnemyType.class);

    public CreatureFactory(EquipmentProvider equipmentProvider) {
        registry.put(EnemyType.NORMAL, () -> {
            NormalCreature creature = new NormalCreature();
            creature.setEquipment(equipmentProvider.getDefaultWeapon());
            return creature;
        });
        registry.put(EnemyType.ELITE, () -> {
            EliteCreature creature = new EliteCreature();
            creature.setEquipment(equipmentProvider.getEliteWeapon());
            creature.setBuff(new EliteBuff());
            return creature;
        });
        registry.put(EnemyType.BOSS, BossCreature::new);
    }

    public Creature create(EnemyType type) {
        Supplier<Creature> creator = registry.get(type);
        if (creator == null) {
            throw new IllegalArgumentException("未知敌人类型: " + type);
        }
        return creator.get();
    }
}

用EnumMap+Supplier替代switch，新增敌人类型时不需要改create方法本身，只往map里注册即可。同时通过构造器注入EquipmentProvider，敌人工厂彻底不再直接依赖具体的装备工厂实现——工厂方法只管创建敌人，装备由外部提供的装备工厂统一生产，职责清晰了，重叠的代码也消失了。

3.6 枚举式单例：全局配置访问入口统一

第一版的GameConfigManager写的是标准的懒加载双检锁单例，但项目里有人习惯用getInstance()，有人直接用静态字段，还有人为了测试方便在工厂里偷偷new了一个新的配置实例。这就导致一个困境：单例模式的“全局唯一性”被实现了，但在使用层面并不可靠。

我改成枚举单例，这是Java社区公认最健壮的单例写法：

java复制public enum GameConfigManager {
    INSTANCE;

    private int playerLevel = 1;
    private double expRate = 1.0;
    private int initialGold = 100;

    public int getPlayerLevel() {
        return playerLevel;
    }

    public void setPlayerLevel(int playerLevel) {
        this.playerLevel = playerLevel;
    }
    // 其他配置项的读写方法...
}

枚举单例的好处是：JVM从语言层面保证只有一个实例，天然线程安全，反序列化也不会产生新实例。更重要的是，整个项目里访问配置的唯一入口变成GameConfigManager.INSTANCE，不会再有两种取法并存。配合前面的泛型装备工厂，取配置的代码也从三份缩成一份。

这一步虽然技术含量不算高，但它是统一全局入口的关键一步。入口不统一，后面所有工厂拿到的配置可能是同一份，也可能是不同副本，行为就无法保证一致了。

4. 重构结果：用数据说话

优化不能只靠感觉说“代码变好了”，得有客观指标。重构后我做了两组统计：一组是代码量对比，一组是行为验证测试的通过情况。

4.1 代码量化对比

类数量减少不代表设计倒退——减少的9个类里，有6个是重复的模板管理器和重复的工厂子类，真正保留的是五种模式的核心骨架类。新增职业的改动从“动4个文件”变成“动2个文件”，说明扩展成本更低了。

还有个值得注意的变化：第一版代码里switch-case出现3处，优化后是0处；if-else判断对象类型出现5处，优化后是2处，且这2处都是配置校验逻辑，属于正常业务规则。模式协作取代了类型判断，这个趋势是我预期中的。

4.2 行为验证：重构后如何保证没改坏

代码重构最怕的是“改完看起来一样，跑到某个分支就崩”。这次重构我专门写了一组行为验证测试，覆盖五个核心场景：

• 单例唯一性测试：连续取10次实例，断言全部是同一个对象。
• 装备工厂一致性测试：同一个职业工厂创建武器和护甲，断言它们属于同一产品族，且攻击/防御值与玩家等级联动正确。
• 建造者校验测试：传入空名称、超长名称，断言抛出的异常类型和消息一致。
• 原型隔离测试：从注册表取两次同一模板，断言是两个不同对象，修改其中一个不影响另一个。
• 敌人工厂注册测试：遍历所有EnemyType，断言每种类型都能正确创建出对应子类对象，未知类型能明确报错。

这组测试本质上是把五种模式的外部契约固定下来，重构只要保证这些契约不破，内部实现随便改。我在实际重构中经历了三次跑挂，全部是原型隔离问题——某个模板对象没有正确实现copy()方法，导致修改克隆体污染了模板本身。这属于深拷贝/浅拷贝的经典问题，后面在常见问题里详细讲。

4.3 哪些“冗余”不该消除

优化过程中我学到的另一课是：不是所有重复都该消除，有些“看起来重复”的代码其实是必要的防御。

• 工厂里对非法参数的防御不能删。比如装备工厂遇到未知职业时抛异常、建造者遇到空名称时抛异常，这些在多个工厂里看着重复，但它们保护的是不同的调用边界，删了会降低容错性。
• 单例和工厂方法各自持有的“读取配置”逻辑可以合并，但单例模式本身的唯一性约束不能因为“省代码”就退化成静态方法包一层。静态方法和枚举单例在行为上并不完全等价，尤其涉及序列化和反射时。
• 建造者里的Director虽然看起来只是“把几个setter按顺序调一遍”，但它是构建流程的编排者。如果为了省代码把Director删掉，调用方就得自己控制构建顺序，这等于把“顺序敏感性”这个复杂度重新抛给了业务层。

这类“可省略但不能省”的代码，恰恰是设计模式最值钱的部分。区分标准和3.1里的职责边界一样：看这段代码承担的职责是不是可以被其他类完整替代，如果不能，再短也要留。

5. 实战心得与常见问题速查

最后这部分是实战过程中沉淀下来的判断方法和踩坑记录，不是理论补充，是这次优化真正值钱的地方。

5.1 一个项目到底该不该用全五种创建型模式

我的看法是：业务项目里刻意用全五种基本不存在，硬凑就是炫技。但这个练习值得做，原因有三：

• 多模式并存的场景最锻炼“职责划分”能力。单用工厂方法时你不会去想它和抽象工厂的边界，五种一起上，边界问题直接逼着你做决策。
• 冗余消除这个动作本身，放在多模式场景里效果最明显。只写两种模式，重复代码的量级不足以暴露架构问题；五种模式一起上，复制粘贴的代价会被放大到没法视而不见。
• 重构的经验可以平移到任何业务项目。这次用到的“公共逻辑上移”、“注册表收敛入口”、“职责边界表格化”，换到订单系统、消息中间件、报表引擎，思路完全通用。

如果你在工作中遇到“类爆炸”问题，大概率不是因为你用了太多设计模式，而是因为这些模式之间缺少协作，像第一版那样各写各的、各管各的。解决办法不是删模式，而是划边界、提公共、统一入口。

5.2 常见问题排查与思路

这次优化和后续给别人代码评审时，我遇到了几个高频问题：

问：为什么我的原型模式总是出现“改一个对象，其他对象跟着变”？

答：99%是浅拷贝问题。只复制了引用字段，没有复制引用指向的对象。解决方法是给所有可变引用字段写深拷贝逻辑，或者在copy()方法里手动new新对象并逐个赋值。测试时专门写“取两次模板，改其中一个，另一个不变”的用例，一步到位。

问：泛型抽象工厂的枚举值里放了数值，会不会导致“配置写死在代码里”？

答：会，前提是你把数值当死配置。我这里的做法是先写在枚举里，后续如果数值需要动态调整，就把枚举里的基础值改为从配置中心读取，枚举只保留键名，值从GameConfigManager.INSTANCE拿。这样既保留了泛型工厂的简洁，又保留了配置外部化的弹性。

问：注册映射（EnumMap+Supplier）和传统的switch-case工厂方法相比，有什么代价？

答：代价是工厂类的初始化逻辑变长、map定义得在构造器或静态块里完成，代码可读性对新人没那么友好。换来的收益是新类型注册时不需要改主方法，符合开闭原则，而且EnumMap的key即枚举，天然防NULL。我的建议是，当switch-case的分支数超过5个、或分支逻辑超过一行时，果断换成注册映射。

问：怎么判断自己提炼的公共父类是不是过度设计？

答：一个简单标准：如果当前状态下，只有一个子类会用到你提炼的方法，那这个抽象大概率是过度设计。等至少两个子类出现重复逻辑时再提取，不迟。我在这次重构里，BaseHeroBuilder是在HeroBuilder和MageHeroBuilder两个子类都出现重复校验后才提取的，不是一上来就抽象。

5.3 补充几点我自己反复踩坑后的心得

• 冗余消除是高收益重构，但一定要用测试兜底，否则“优化”很容易变成“优化式重写”。
• 模式协作的复杂度并不和类数量成正比。真正决定复杂度的是：调用方需不需要知道具体实现类。第一版12处直接依赖具体工厂，优化后4处，这才是复杂度下降的根本原因。
• 碰到“两个模式职责重叠”时，不要急着删代码，先画一张职责边界表（类似3.1那张），双方都按表执行。表定清楚了，代码自然就干净了。
• 枚举类做注册表时，注意枚举的构造器里不要访问外部静态方法或依赖初始化顺序的全局状态，否则JVM加载枚举时可能踩到初始化顺序的坑。模板初始化逻辑放在构造器里没问题，但如果构造逻辑需要读配置文件，建议改成懒加载。

整个项目做到最后，最让我满意的不是五种模式凑齐了，而是每次看代码都能很快说出“这个类的职责是什么、它不该做什么”。代码量小了，边界清楚了，测试跑得稳。希望这篇复盘能帮你在自己的项目里少走几步弯路。