JS如何实现建造者模式？建造者的步骤

冬静酱_3580

发布时间：2025-08-24 10:33:01

553人浏览过

来源于php中文网

原创

建造者模式通过分离复杂对象的构建与表示，使同一构建过程可生成不同配置的对象，适用于参数多、配置灵活的场景，如前端组件、表单、API请求的构建，提升代码可读性与维护性，但应避免在简单对象上过度设计。

js如何实现建造者模式？建造者的步骤

JavaScript中实现建造者模式，核心在于将一个复杂对象的构建过程与其表示分离。说白了，就是把创建对象的那一堆零碎步骤，从对象本身的类里抽出来，放到一个专门的“建造者”手里。这样一来，你就能用同样的构建过程，生成不同配置的对象，或者反过来，用不同的步骤组合出同一种类的对象。它特别适合那些构造函数参数多到爆炸，或者对象在不同场景下需要不同初始化配置的情况。

解决方案

要实现建造者模式，我们通常需要几个角色：产品（Product）、建造者（Builder）、具体建造者（Concrete Builder）以及指挥者（Director，可选）。

在JavaScript里，这大概是这么个思路：

产品（Product）: 这就是我们最终想要构建的复杂对象。它不需要知道自己是如何被构建的。

class Car {
    constructor() {
        this.engine = null;
        this.wheels = 0;
        this.color = 'white';
        this.gps = false;
    }

    describe() {
        console.log(`这是一辆${this.color}的汽车，配备${this.engine}引擎，${this.wheels}个轮子，${this.gps ? '有' : '没有'}GPS。`);
    }
}

建造者（Builder）: 定义构建产品各个部分的抽象接口。在JS中，这通常是一个类，包含设置产品不同属性的方法，以及一个返回最终产品的方法。

class CarBuilder {
    constructor() {
        this.car = new Car(); // 内部持有待构建的产品实例
    }

    setEngine(engineType) {
        this.car.engine = engineType;
        return this; // 链式调用
    }

    setWheels(count) {
        this.car.wheels = count;
        return this;
    }

    setColor(color) {
        this.car.color = color;
        return this;
    }

    addGPS() {
        this.car.gps = true;
        return this;
    }

    build() {
        // 在这里可以做一些最终的校验或组装工作
        if (!this.car.engine || this.car.wheels === 0) {
            console.warn("警告：汽车缺少引擎或轮子，可能无法正常行驶！");
        }
        return this.car;
    }
}

指挥者（Director，可选）: 这个角色其实不是必须的，但当你有多种标准化的构建流程时，它就显得很有用了。它知道如何使用建造者来构建特定类型的产品。它封装了构建产品的复杂性。

class CarDirector {
    constructSportsCar(builder) {
        builder.setEngine('V8').setWheels(4).setColor('red').addGPS();
        return builder.build();
    }

    constructCityCar(builder) {
        builder.setEngine('Inline-4').setWheels(4).setColor('blue');
        return builder.build();
    }

    // 也可以有更复杂的构建方法
    constructCustomCar(builder, config) {
        if (config.engine) builder.setEngine(config.engine);
        if (config.wheels) builder.setWheels(config.wheels);
        if (config.color) builder.setColor(config.color);
        if (config.hasGPS) builder.addGPS();
        return builder.build();
    }
}

实际使用：

// 不使用Director，直接使用Builder
const myLuxuryCar = new CarBuilder()
    .setEngine('V12')
    .setWheels(4)
    .setColor('black')
    .addGPS()
    .build();
myLuxuryCar.describe();
// 输出：这是一辆black的汽车，配备V12引擎，4个轮子，有GPS。

// 使用Director
const director = new CarDirector();
const builder = new CarBuilder();

const sportsCar = director.constructSportsCar(builder);
sportsCar.describe();
// 输出：这是一辆red的汽车，配备V8引擎，4个轮子，有GPS。

// 每次构建新对象，都需要一个新的builder实例，以避免状态污染
const cityCar = director.constructCityCar(new CarBuilder());
cityCar.describe();
// 输出：这是一辆blue的汽车，配备Inline-4引擎，4个轮子，没有GPS。

为什么在JavaScript中选择建造者模式，它解决哪些痛点？

我个人觉得，在JavaScript里，建造者模式的魅力在于它能优雅地处理那些“参数爆炸”的场景。想象一下，你有一个组件，它有十几个可选配置项，比如一个弹窗组件，它可能有标题、内容、按钮文本、点击回调、关闭图标是否显示、背景是否可点击关闭、动画类型等等。如果这些都塞进构造函数，那构造函数签名会变得无比冗长，而且你得传一堆

null

或

undefined

来跳过不需要的参数。这简直是灾难。

建造者模式直接解决了所谓的“伸缩构造函数”（Telescoping Constructor）反模式。你不再需要为不同数量的参数写一堆重载的构造函数（JS里本来就没有函数重载这回事，所以你只能用一个大对象作为参数，但这又引入了新的问题，比如类型不明确，IDE提示不友好）。通过链式调用，代码可读性一下就上去了，每次调用一个

setXxx

方法，意图都非常明确，构建过程也变得清晰可见。

它还解决了构建过程中对象状态不一致的问题。在构建完成前，产品对象可能处于一种不完整的状态。建造者模式将这个中间状态封装在建造者内部，直到

build()

方法被调用，才返回一个完整的、合法的对象。这避免了外部代码在对象未完全构建时就对其进行操作，从而减少了潜在的bug。

而且，当你的构建逻辑本身需要变动，比如有时需要构建一个“豪华版”对象，有时需要“标准版”，但它们都属于同一类产品时，建造者模式能让你在不修改产品类本身的情况下，通过不同的建造者或指挥者来灵活地实现这些变种。这对于维护和扩展来说，简直是福音。

建造者模式在前端开发中有哪些实际应用场景？

在前端开发中，我发现建造者模式特别有施展拳脚的空间，尤其是当你面对那些“巨无霸”配置对象时。

AI舌诊面诊问诊医疗系统+诊疗商城系统源码

AI 舌诊面诊问诊医疗系统 + 诊疗商城系统源码是一套结合 AI 辅助诊断与商品转化的健康类程序，基于浩创云、ThinkPHP（PHP）开发，支持微信服务号与 H5 端，适合做中医舌诊面诊问答、健康建议推送以及配套诊疗商品的运营。

下载

一个很典型的例子是UI组件的配置。比如，你需要创建一个高度可定制的图表组件。这个图表可能有不同的数据源、图例位置、轴线样式、工具提示格式、交互行为等等。如果直接通过一个巨大的配置对象来初始化，你会发现那个配置对象会变得非常复杂，而且每次使用时，你可能只关心其中一小部分。用建造者模式，你可以这样写：

// 假设 ChartBuilder 已经定义好
const myChart = new ChartBuilder()
    .setData(someDataSource)
    .setType('bar')
    .setAxisLabelsVisible(true)
    .setLegendPosition('top-right')
    .enableTooltip()
    .addClickEventHandler(handleBarClick)
    .build();

这比直接传一个

{ data: ..., type: 'bar', axisLabelsVisible: true, ... }

的对象要清晰得多，而且具备更好的智能提示。

另一个场景是复杂表单的动态构建。想象一个表单，根据用户角色或业务逻辑，需要动态地添加或移除字段，甚至调整字段的校验规则和布局。你可以有一个

FormBuilder

，通过一系列

addField()

addValidation()

setLayout()

等方法来逐步构建出最终的表单配置或DOM结构。

再比如，API请求的构建。如果你在做一个需要与多个后端服务交互的客户端，每个服务的API请求头、认证方式、查询参数、请求体结构可能都有细微差异。一个

HttpRequestBuilder

就能很好地管理这些复杂性，比如：

const apiRequest = new HttpRequestBuilder()
    .setMethod('POST')
    .setEndpoint('/api/v1/users')
    .setAuthToken(userToken)
    .addHeader('X-Custom-Header', 'value')
    .setBody({ name: 'John Doe', email: 'john@example.com' })
    .setTimeout(5000)
    .build();
// 然后你可以用这个 request 对象去发送请求

这些场景都体现了建造者模式的核心价值：将复杂对象的构建过程模块化、可读化，并提供灵活的配置方式。

如何避免滥用建造者模式，以及其潜在的局限性？

建造者模式确实好用，但任何模式都有其适用范围和潜在的坑。我见过一些项目，为了“模式化”而模式化，结果把简单的事情搞复杂了。

最大的一个误区就是过度设计（Over-engineering）。如果你的对象非常简单，只有两三个属性，而且构造逻辑也很直白，那直接用构造函数或者一个简单的工厂函数就足够了。引入建造者模式会凭空增加好几个类或对象，代码量和概念复杂度都上去了，收益却微乎其微。这就像为了拧一个螺丝，非得搬出一整套精密工具箱，结果效率反而降低了。

再来就是增加了代码的间接性。你不再是直接