java设计模式:02-05-建造者模式

建造者模式(Builder Pattern)

建造者模式(Builder Pattern)是一种创建型设计模式,它通过一步一步的构造来创建一个复杂的对象,允许用户通过构建过程来定制他们的对象。这种模式特别适合创建复杂的对象时使用,以避免构造函数参数过多或者构造过程复杂的情况。

建造者模式的应用场景

  • 对象的创建过程复杂,需要一步一步的构造:如创建一个包含多个子对象的复杂对象。
  • 同一个构造过程可以创建不同的表示:如在不同配置下生成不同版本的对象。
  • 当创建复杂对象需要灵活的配置和顺序控制时:如创建一个复杂的UI控件或数据结构。

建造者模式的实现方式

1. 传统实现方式

思想:通过定义一个Builder接口来抽象化对象的构建步骤,每一个具体的Builder类负责实现这些步骤。Director类负责调用Builder的具体实现来构建最终的对象。

实现方式:

java 复制代码
// 产品类
class Product {
    private String partA;
    private String partB;
    private String partC;

    public void setPartA(String partA) {
        this.partA = partA;
    }

    public void setPartB(String partB) {
        this.partB = partB;
    }

    public void setPartC(String partC) {
        this.partC = partC;
    }

    @Override
    public String toString() {
        return "Product [partA=" + partA + ", partB=" + partB + ", partC=" + partC + "]";
    }
}

// 抽象建造者接口
interface Builder {
    void buildPartA();
    void buildPartB();
    void buildPartC();
    Product getResult();
}

// 具体建造者类
class ConcreteBuilder implements Builder {
    private Product product = new Product();

    public void buildPartA() {
        product.setPartA("Part A");
    }

    public void buildPartB() {
        product.setPartB("Part B");
    }

    public void buildPartC() {
        product.setPartC("Part C");
    }

    public Product getResult() {
        return product;
    }
}

// 指挥者类
class Director {
    private Builder builder;

    public Director(Builder builder) {
        this.builder = builder;
    }

    public Product construct() {
        builder.buildPartA();
        builder.buildPartB();
        builder.buildPartC();
        return builder.getResult();
    }
}

// 客户端代码
public class BuilderPattern {
    public static void main(String[] args) {
        Builder builder = new ConcreteBuilder();
        Director director = new Director(builder);
        Product product = director.construct();
        System.out.println(product);
    }
}

优点:

  • 将复杂对象的创建过程封装在建造者中,使得客户端代码简洁。
  • 各个建造过程可以灵活组合,便于扩展。
  • 可以控制构造的细节和顺序,提高代码的可读性和维护性。

缺点:

  • 需要定义多个Builder类和Director类,增加了系统的复杂度。
  • 适用于构建过程固定的对象,不适合变化多端的对象创建。
2. 使用嵌套类实现建造者模式

思想:通过在产品类内部定义一个静态的Builder类,使得建造过程更加内聚和简洁。这种方式特别适合于需要灵活配置的对象创建。

实现方式:

java 复制代码
class Product {
    private final String partA;
    private final String partB;
    private final String partC;

    private Product(Builder builder) {
        this.partA = builder.partA;
        this.partB = builder.partB;
        this.partC = builder.partC;
    }

    public static class Builder {
        private String partA;
        private String partB;
        private String partC;

        public Builder setPartA(String partA) {
            this.partA = partA;
            return this;
        }

        public Builder setPartB(String partB) {
            this.partB = partB;
            return this;
        }

        public Builder setPartC(String partC) {
            this.partC = partC;
            return this;
        }

        public Product build() {
            return new Product(this);
        }
    }

    @Override
    public String toString() {
        return "Product [partA=" + partA + ", partB=" + partB + ", partC=" + partC + "]";
    }
}

public class BuilderPatternNested {
    public static void main(String[] args) {
        Product product = new Product.Builder()
            .setPartA("Part A")
            .setPartB("Part B")
            .setPartC("Part C")
            .build();
        System.out.println(product);
    }
}

优点:

  • 内部类Builder使得建造过程内聚,代码更简洁。
  • 通过链式调用的方式,灵活配置对象的各个部分。
  • 可以在产品类内部定义更多的约束和逻辑,确保对象的一致性。

缺点:

  • 当产品类很复杂时,嵌套类也会变得复杂。
  • 内部类Builder不能很好地支持继承,扩展性有限。

总结

实现方式 优点 缺点
传统实现方式 将复杂对象的创建过程封装在建造者中,使客户端代码简洁 需要定义多个Builder类和Director类,增加了系统的复杂度
使用嵌套类实现 内部类Builder使建造过程内聚,代码更简洁,链式调用灵活配置 产品类复杂时,嵌套类也会变得复杂,内部类Builder扩展性有限

选择哪种实现方式应根据具体的需求和系统的复杂度来决定。如果系统中需要创建的对象结构较为复杂且构建过程需要灵活控制,传统实现方式较为合适。如果对象的创建需要灵活配置且对象结构相对固定,使用嵌套类实现的方式更加简洁和内聚。

相关推荐
SL_staff1 小时前
私有化低代码:面向强监管行业的可控数字化实践
java·低代码
三翼鸟数字化技术团队1 小时前
高性能存储引擎RocksDB:原理与Java生态实践
java
SL_staff2 小时前
JVS-APS有限产能建模的七个刚性支点:面向产线真实约束的技术实现解析
java·开源·全栈
特立独行的猫A2 小时前
少 3 个环节、少 1 次 ABI、少 3500 行代码:cj-tauri 与 Ionic/Capacitor 的鸿蒙桥接机制对比
java·后端·python
学长毕设2 小时前
基于SpringBoot的高校后勤报修管理系统-附源码
java·spring boot·后端
特立独行的猫A2 小时前
cj-tauri vs Rust/Tauri 同款播放器实测:编译 21 秒 vs 11 分钟,磁盘 12 MB vs 1.2 GB
java·后端·python
杨凯凡3 小时前
Spring AI RAG 实战:向量检索、租户过滤、引用溯源与防幻觉边界
java·人工智能·spring
小科先生3 小时前
Java springboot调用数据库的基本流程
java·数据库·spring boot
秋饼4 小时前
GPT-Live 全双工语音 API Java 服务端落地实战:事件协议、会话恢复与生产踩坑
java·ai·技术分享·后端开发
SL_staff4 小时前
为什么企业级自动化不能只靠AI编排?——逻辑引擎在确定性业务场景中的不可替代性
java·开源·产品