建造者模式是什么？和Lombok@Builder有哪些不同？

 建造者模式是什么？

建造者模式是一种创建型对象模式

我们经常看到有很多的框架都为我们提供了形如XXXBuilder的类型，我们一般也是使用这些类来创建我们需要的对象。

 

 

 

我们通常将建造者模式分为四个角色：产品（Product）、抽象建造者（Builder）、具体建造者（ConcreteBuilder）和指挥者（Director）

 

 

Lombok@Builder

现在我有一个实体类：

@Data
@Builder
public class Story {
    private String id;
    private String title;
    private String content;
}

当在 Story 类上使用 @Builder 时，Lombok会自动生成一个建造者类，但不是完整的建造者模式四要素

1. 自动生成的代码结构

下面是Lombok 实际生成的代码：

查看代码

// Lombok 实际生成的代码：
public class Story {
    private String id;
    private String title;
    private String content;
    
    // 自动生成的建造者类
    public static class StoryBuilder {
        private String id;
        private String title;
        private String content;
        
        StoryBuilder() {}
        
        public StoryBuilder id(String id) {
            this.id = id;
            return this;
        }
        
        public StoryBuilder title(String title) {
            this.title = title;
            return this;
        }
        
        public StoryBuilder content(String content) {
            this.content = content;
            return this;
        }
        
        public Story build() {
            return new Story(this.id, this.title, this.content);
        }
        
        public String toString() {
            return "Story.StoryBuilder(id=" + this.id + ", title=" + this.title + ", content=" + this.content + ")";
        }
    }
    
    // 静态工厂方法
    public static StoryBuilder builder() {
        return new StoryBuilder();
    }
    
    // 全参数构造器（由@Builder生成）
    public Story(String id, String title, String content) {
        this.id = id;
        this.title = title;
        this.content = content;
    }
    
    // 默认构造器和其他getter/setter...
}

2. 与传统建造者模式的对比

传统建造者模式	Lombok @Builder
产品类 (Product)	实体类 (如 Story)
抽象建造者 (Builder接口)	❌ 没有生成接口
具体建造者 (ConcreteBuilder)	✅ 自动生成 StoryBuilder 内部类
指挥者 (Director)	❌ 没有生成专门的指挥者

 

总结

Lombok @Builder 自动生成了具体建造者类，但没有生成抽象建造者接口和专门的指挥者类。建造者模式的"指挥"职责由客户端代码承担。

这种设计在大多数业务场景下是完全足够的，因为：

1. 我们很少需要同一个产品的多种建造方式

2. 构建逻辑通常比较简单，不需要专门的指挥者封装

3. 代码简洁性比模式完整性更重要