如何通过构建器模式消除枚举驱动的 if-else 代码异味-java教程-PHP中文网

如何通过构建器模式消除枚举驱动的 if-else 代码异味

本文介绍一种面向 API 设计的重构方案：用语义明确的构建器方法（如 putTextProperty、putKeywordProperty）替代基于 Property.Kind 枚举的冗长 if-else 分支，从而提升可读性、可维护性与扩展性，同时完全规避反射、Map 查表或策略枚举等复杂间接层。

本文介绍一种面向 api 设计的重构方案：用语义明确的构建器方法（如 `puttextproperty`、`putkeywordproperty`）替代基于 `property.kind` 枚举的冗长 if-else 分支，从而提升可读性、可维护性与扩展性，同时完全规避反射、map 查表或策略枚举等复杂间接层。

在 OpenSearch Java 客户端（v2.4.0）中构建 TypeMapping 时，常见的反模式是将 Property.Kind 枚举作为分支条件，通过大量 if-else 或 switch 语句调用不同 Builder 方法（如 .text(...)、.keyword(...)）。这种写法不仅造成严重代码异味（重复逻辑、违反开闭原则、难以测试），还迫使调用方传递“类型标识”而非表达真实意图，削弱了 API 的自解释性。

✅ 推荐方案：职责前移 + 语义化构建器方法

核心思想是将执行路径的选择权交给调用方——不再由构建器内部根据枚举判断“该建什么”，而是由调用方直接调用含义清晰的方法名（如 putTextProperty），让意图一目了然：

// ✅ 清晰、自解释、无需文档即可理解
TypeMappingBuilder builder = new TypeMappingBuilder();
builder.putTextProperty("title", true, Map.of())
       .putKeywordProperty("status", false, Map.of())
       .putLongProperty("age", true, null)
       .build();

对应构建器实现简洁且无分支：

public class TypeMappingBuilder {
    private final Map<string property> properties = new HashMap();

    public TypeMappingBuilder putTextProperty(
            String name,
            boolean shouldIndex,
            Map<string property> subTypeProperties) {
        Property prop = new Property.Builder()
                .text(p -> p.index(shouldIndex).fields(subTypeProperties))
                .build();
        properties.put(name, prop);
        return this;
    }

    public TypeMappingBuilder putKeywordProperty(
            String name,
            boolean shouldIndex,
            Map<string property> subTypeProperties) {
        Property prop = new Property.Builder()
                .keyword(p -> p.index(shouldIndex).fields(subTypeProperties))
                .build();
        properties.put(name, prop);
        return this;
    }

    public TypeMappingBuilder putLongProperty(
            String name,
            boolean shouldIndex,
            Map<string property> subTypeProperties) {
        Property prop = new Property.Builder()
                .long_(p -> p.index(shouldIndex).fields(subTypeProperties)) // 注意 long_ 是保留字转义
                .build();
        properties.put(name, prop);
        return this;
    }

    // ... 其他类型方法（date, boolean, object 等），按需添加，不修改现有逻辑

    public TypeMapping build() {
        return new TypeMapping.Builder()
                .properties(properties)
                .build();
    }
}</string></string></string></string>

? 为什么这是最优解？

维度	传统 if-else 方案	语义化构建器方案
可读性	`getTypeProperty(Kind.Text, true, ...)` —— 需查文档理解 `Kind.Text` 含义	`putTextProperty(...)` —— 方法名即契约，零认知成本
可维护性	新增类型需修改 `getTypeProperty()`，违反开闭原则	新增类型只需添加新方法，旧代码零影响
扩展性	反射/Map/策略枚举引入额外抽象层和运行时开销	纯编译期绑定，零性能损耗，类型安全
API 设计质量	暴露内部实现细节（`Property.Kind`）	隐藏实现，暴露意图（`putXxxProperty`）

? 关键洞察：Property.Kind 本质不是领域模型，而是控制流标记（control-flow token）。将其保留在 API 中，是典型的“过早泛化”。真正需要泛化的，是客户端使用场景（如注解驱动的 MappingFactory），而非构建器本身。

? 与 `MappingFactory` 的协同设计

当同时支持 TypeMappingBuilder（显式调用）和 MappingFactory（注解驱动）两种方式时，建议分层解耦：

TypeMappingBuilder：专注提供人类友好的、不可变的、链式构建 API，不依赖任何外部配置或反射；
MappingFactory：独立封装反射逻辑，内部仍可复用相同的构建器方法（避免重复构造逻辑）：

class MappingFactory {
    public static Map<string property> getMapping(Class> clazz) {
        ImmutableMap.Builder<string property> builder = ImmutableMap.builder();
        ReflectionUtils.doWithFields(clazz, field -> {
            TypeAnnotation ann = field.getAnnotation(TypeAnnotation.class);
            String name = ann.name();
            Type type = ann.type();
            boolean index = ann.index();
            Map<string property> subProps = getSubProperties(field); // 自定义逻辑

            // 复用构建器中的构造逻辑（可提取为静态工具类）
            Property prop = PropertyConstructors.create(type, index, subProps);
            builder.put(name, prop);
        });
        return builder.build();
    }
}

// 提取共用构造逻辑（非必须，但利于复用）
class PropertyConstructors {
    static Property create(Type type, boolean index, Map<string property> subProps) {
        return switch (type) {
            case TEXT -> new Property.Builder().text(p -> p.index(index).fields(subProps)).build();
            case KEYWORD -> new Property.Builder().keyword(p -> p.index(index).fields(subProps)).build();
            case LONG -> new Property.Builder().long_(p -> p.index(index).fields(subProps)).build();
            // ... 其他 case，仅用于内部反射场景，不影响公共 API
        };
    }
}</string></string></string></string>

此设计确保：