java/android 设计模式学习笔记（10）---建造者模式

　　这篇博客我们来介绍一下建造者模式（Builder Pattern），建造者模式又被称为生成器模式，是创造性模式之一，与工厂方法模式和抽象工厂模式不同，后两者的目的是为了实现多态性，而 Builder 模式的目的则是为了将对象的构建与展示分离。Builder 模式是一步一步创建一个复杂对象的创建型模式，它允许用户在不知道内部构建细节的情况下，可以更精细地控制对象的构造流程。一个复杂的对象有大量的组成部分，比如汽车它有车轮、方向盘、发动机、以及各种各样的小零件，要将这些部件装配成一辆汽车，这个装配过程无疑会复杂，对于这种情况，为了实现在构建过程中对外部隐藏具体细节，就可以使用 Builder 模式将部件和组装过程分离，使得构建过程和部件都可以自由扩展，同时也能够将两者之间的耦合降到最低。

　　转载请注明出处：http://blog.csdn.net/self_study/article/details/51707029。

　　PS：对技术感兴趣的同鞋加群544645972一起交流。

设计模式总目录

　　java/android 设计模式学习笔记目录

特点

　　将一个复杂对象的构建和它的表示分离，使得同样的构建过程可以创建不同的表示。Builder 模式适用的使用场景：

  • 相同的方法，不同的执行顺序，产生不同的事件结果；
  • 多个部件或零件，都可以装配到一个对象中，但是产生的运行结果又不相同时；
  • 产品类非常复杂，或者产品类中的调用顺序不同产生不同的作用，这个时候使用建造者模式非常适合；
  • 当初始化一个对象特别复杂，如参数多，且很多参数都具有默认值时。

　　在实际开发过程中，Builder 模式可以使用工厂模式或者任一其他创建型模式去生成自己的指定组件，Builder 模式也是实现 fluent interface 一种非常好的方法。

UML类图

　　Builder 模式的 uml 类图如下所示：

　　

有四个角色：

  • Product 产品模块

    • 产品的相关类；

  • Builder 接口或抽象类

    • 规范产品的组件，一般是由子类实现具体的组件过程，需要注意的是这个角色在实际使用过程中可以省略，最典型的就是像 AlertDialog.Builder 一样，省略 Builder 虚拟类，将 ConcreteBuilder 写成一个静态内部类；

  • ConcreateBuilder 类

    • 具体的 Builder 类；

  • Director 类

    • 统一组装过程，同样值得注意的是，在现实开发过程中，Director 角色也经常会被省略，而直接使用一个 Builder 来进行对象的组装，这个 Builder 通常为链式调用，也就是上面提到的 fluent interface ，它的关键点是每个 setter 方法都返回自身，也就是 return this，这样就使得 setter 方法可以链式调用，最典型的仍然是 AlertDialog.Builder 类，使用这种方式不仅去除了 Director 角色，使得整个结构更加简单，也能对 Product 对象的组件过程有着更精细的控制。

　　据此我们可以写出 Builder 模式的通用代码：

Product.class

public class Product {

    public int partB;
    public int partA;

    public int getPartA() {
        return partA;
    }
    public void setPartA(int partA) {
        this.partA = partA;
    }

    public int getPartB() {
        return partB;
    }
    public void setPartB(int partB) {
        this.partB = partB;
    }

    @Override
    public String toString() {
        return "partA : " + partA + "   partB : " + partB;
    }
}

产品类在此声明了两个 setter 方法，然后是 Builder 相关类：

Builder.class

public abstract class Builder {
    public abstract void buildPartA(int partA);

    public abstract void buildPartB(int partB);

    public abstract Product build();
}

ConcreteBuilder.class

public class ConcreteBuilder extends Builder{
    private Product product = new Product();

    @Override
    public void buildPartA(int partA) {
        product.setPartA(partA);
    }

    @Override
    public void buildPartB(int partB) {
        product.setPartB(partB);
    }

    @Override
    public Product build() {
        return product;
    }
}

Builder 这两个类用来封装对 Product 属性的设置，最后在 build 方法中返回设置完属性的 Product 对象，最后是 Director 角色：

Director.class

public class Director {
    private Builder builder;

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

    public void construct(int partA, int partB) {
        builder.buildPartA(partA);
        builder.buildPartB(partB);
    }
}

封装了 Builder 对象，最后是测试程序：

Builder builder = new ConcreteBuilder();
Director director = new Director(builder);
director.construct(1, 2);
Product product = builder.build();
Log.e("shawn", product.toString());
break;

运行结果

com.android.builderpattern E/shawn: partA : 1   partB : 2

代码一目了然，这里需要提到的一点是针对不同的产品可以去构建不同的 ConcreteBuilder 类，使得一个 ConcreteBuilder 类对应一个 Product 类，这点和工厂方法模式很类似，我们后面也会介绍到他们两者之间的区别。

示例与源码

　　Builder 模式在实际开发中出现和使用的频率也是很高的，比如上面提到的 AlertDialog.Builder ，还比如非常有名的第三方开源框架 Universal-Image-Loader 库中的 ImageLoaderConfig ，他们都是使用的静态内部 Builder 类。

　　这里的 demo 也使用最简单的内部静态 Builder 类去实现，精简完之后只有 ConcreteBuilder 和 Product 角色，并且使用链式调用去实现上面提到的 fluent interface：

Computer.class

public class Computer {
    private String CPU;
    private String GPU;
    private String memoryType;
    private int memorySize;
    private String storageType;
    private int storageSize;
    private String screenType;
    private float screenSize;
    private String OSType;

    public static class Builder {
        // Optional parameters - initialize with default values
        private String CPU = "inter-i3";
        private String GPU = "GTX-960";
        private String memoryType = "ddr3 1666MHz";
        private int memorySize = 8;//8GB
        private String storageType = "hdd";
        private int storageSize = 1024;//1TB
        private String screenType = "IPS";
        private float screenSize = 23.8f;
        private String OSType = "Windows 10";

        public Builder() {
        }

        public Builder setCPU(String CPU) {
            this.CPU = CPU;
            return this;
        }

        public Builder setGPU(String GPU) {
            this.GPU = GPU;
            return this;
        }
        public Builder setMemoryType(String memoryType) {
            this.memoryType = memoryType;
            return this;
        }

        public Builder setMemorySize(int memorySize) {
            this.memorySize = memorySize;
            return this;
        }
        public Builder setStorageType(String storageType) {
            this.storageType = storageType;
            return this;
        }

        public Builder setStorageSize(int storageSize) {
            this.storageSize = storageSize;
            return this;
        }

        public Builder setScreenType(String screenType) {
            this.screenType = screenType;
            return this;
        }
        public Builder setScreenSize(float screenSize) {
            this.screenSize = screenSize;
            return this;
        }

        public Builder setOSType(String OSType) {
            this.OSType = OSType;
            return this;
        }

        public Computer create() {
            return new Computer(this);
        }

    }

    private Computer(Builder builder) {
        CPU = builder.CPU;
        GPU = builder.GPU;
        memoryType = builder.memoryType;
        memorySize = builder.memorySize;
        storageType = builder.storageType;
        storageSize = builder.storageSize;
        screenType = builder.screenType;
        screenSize = builder.screenSize;
        OSType = builder.OSType;
    }
}

Computer 为产品类，它有一个 Builder 的静态内部类用于设置相关属性，测试代码：

Computer computer = new Computer.Builder()
        .setCPU("inter-skylake-i7")
        .setGPU("GTX-Titan")
        .setMemoryType("ddr4-2133MHz")
        .setMemorySize(16)
        .setStorageType("ssd")
        .setStorageSize(512)
        .setScreenType("IPS")
        .setScreenSize(28)
        .setOSType("Ubuntu/Window10")
        .create();

这里需要提到的关键点是关于相关属性的默认值问题：

  • 对于必要的属性值，无法给出其默认值的最好是通过 Builder 类的构造函数传入，比如 AlertDialog.Builder 类的 Context，这样也能防止使用时的疏忽；
  • 对于非必要属性来说，最好是为其生成一个默认的属性值，这样使用者只用设置需要更改的属性即可；
  • 每个 setter 函数都加上 return this 用来实现优美的 fluent interface 设计。

总结

　　Builder 模式在 Android 开发中也很常用，通常作为配置类的构建器将配置的构建和表示分离开来，同时也将配置从目标类中隔离开来，避免了过多的 setter 方法。Builder 模式比较常见的实现形式是通过调用链实现，这样的方式也会使得代码更加简洁和易懂，而且同时也可以避免了目标类被过多的接口“污染”。

　　Builder 模式的优点：

  1. 将一个复杂对象的创建过程封装起来，使得客户端不必知道产品内部组成的细节；
  2. 允许对象通过多个步骤来创建，并且可以改变过程和选择需要的过程；
  3. 产品的实现可以被替换，因为客户端只看到一个抽象的接口；
  4. 创建者独立，容易扩展。

Builder 模式缺点：

  1. 会产生多余的 Builder 对象以及 Director 对象，消耗内存；
  2. 与工厂模式相比，采用 Builder 模式创建对象的客户，需要具备更多的领域知识。

Builder 模式 VS 工厂方法模式

　　Builder 模式和工厂方法模式都是属于创建型模式，他们有一些共同点：这两种设计模式的都将一个产品类对象的创建过程封装起来，让客户端从具体产品类的生成中解耦，不必了解产品类构造的细节。但是其实他们两种设计模式还是有很多不同点：

  • Builder 模式允许对象的创建通过多个步骤来创建，而且可以改变这个过程，也可以选择需要改变的属性；工厂方法模式不一样，它只有一个步骤，也就无法改变这个过程，更加无法选择性改变属性了；
  • Builder 模式的目的是将复杂对象的构建和它的表示分离；而工厂方法模式则是定义一个创建对象的接口，由子类决定要实例化的类是哪一个，将实例化推迟到子类；
  • 最明显的当然还是代码的差异，Builder 模式中客户端可以调用 set 方法，而工厂方法模式只能调用工厂类提供的相关方法。

其次是 uml 类图的差异：

Builder 模式 uml 类图：

　　

注：Director 类和 Builder 虚拟类可以被精简。

工厂方法模式 uml 类图：

　　

uml 类图的相似性还是很高的，所以通常我们会根据实际表现和用途来区别 Buidler 模式和工厂方法模式（这点和装饰者模式与保护代理模式的区别类似，要从实际表现与使用的目的区别）。

源码下载

　　https://github.com/zhaozepeng/Design-Patterns/tree/master/BuilderPattern

引用

http://blog.csdn.net/jason0539/article/details/44992733

https://en.wikipedia.org/wiki/Builder_pattern

时间： 2024-10-18 14:07:51

java/android 设计模式学习笔记（10）---建造者模式的相关文章

java/android 设计模式学习笔记（13）---享元模式

这篇我们来介绍一下享元模式(Flyweight Pattern),Flyweight 代表轻量级的意思,享元模式是对象池的一种实现.享元模式用来尽可能减少内存使用量,它适合用于可能存在大量重复对象的场景,缓存可共享的对象,来达到对象共享和避免创建过多对象的效果,这样一来就可以提升性能,避免内存移除和频繁 GC 等. 享元模式的一个经典使用案例是文本系统中图形显示所用的数据结构,一个文本系统能够显示的字符种类就是那么几十上百个,那么就定义这么些基础字符对象,存储每个字符的显示外形和其他的格式化数据

java/android 设计模式学习笔记（3）---工厂方法模式

这篇来介绍一下工厂方法模式(Factory Method Pattern),在实际开发过程中我们都习惯于直接使用 new 关键字用来创建一个对象,可是有时候对象的创造需要一系列的步骤:你可能需要计算或取得对象的初始设置:选择生成哪个子对象实例:或在生成你需要的对象之前必须先生成一些辅助功能的对象,这个时候就需要了解该对象创建的细节,也就是说使用的地方与该对象的实现耦合在了一起,不利于扩展,为了解决这个问题就需要用到我们的工厂方法模式,它适合那些创建复杂的对象的场景,工厂方法模式也是一个使用频率很

java/android 设计模式学习笔记（5）---对象池模式

这次要介绍一下对象池模式(Object Pool Pattern),这个模式为常见 23 种设计模式之外的设计模式,介绍的初衷主要是在平时的 android 开发中经常会看到,比如 ThreadPool 和 MessagePool 等. 在 java 中,所有对象的内存由虚拟机管理,所以在某些情况下,需要频繁创建一些生命周期很短使用完之后就可以立即销毁,但是数量很大的对象集合,那么此时 GC 的次数必然会增加,这时候为了减小系统 GC 的压力,对象池模式就很适用了.对象池模式也是创建型模式之一,

java/android 设计模式学习笔记（14）---外观模式

这篇博客来介绍外观模式(Facade Pattern),外观模式也称为门面模式,它在开发过程中运用频率非常高,尤其是第三方 SDK 基本很大概率都会使用外观模式.通过一个外观类使得整个子系统只有一个统一的高层的接口,这样能够降低用户的使用成本,也对用户屏蔽了很多实现细节.当然,在我们的开发过程中,外观模式也是我们封装 API 的常用手段,例如网络模块.ImageLoader 模块等.其实我们在开发过程中可能已经使用过很多次外观模式,只是没有从理论层面去了解它. 转载请注明出处:http://bl

java/android 设计模式学习笔记（7）---装饰者模式

这篇将会介绍装饰者模式(Decorator Pattern),装饰者模式也称为包装模式(Wrapper Pattern),结构型模式之一,其使用一种对客户端透明的方式来动态的扩展对象的功能,同时它也是继承关系的一种替代方案之一,但比继承更加灵活.在现实生活中也可以看到很多装饰者模式的例子,或者可以大胆的说装饰者模式无处不在,就拿一件东西来说,可以给它披上无数层不一样的外壳,但是这件东西还是这件东西,外壳不过是用来扩展这个东西的功能而已,这就是装饰者模式,装饰者的这个角色也许各不相同但是被装饰的对

java/android 设计模式学习笔记（12）---组合模式

这篇我们来介绍一下组合模式(Composite Pattern),它也称为部分整体模式(Part-Whole Pattern),结构型模式之一.组合模式比较简单,它将一组相似的对象看作一个对象处理,并根据一个树状结构来组合对象,然后提供一个统一的方法去访问相应的对象,以此忽略掉对象与对象集合之间的差别.这个最典型的例子就是数据结构中的树了,如果一个节点有子节点,那么它就是枝干节点,如果没有子节点,那么它就是叶子节点,那么怎么把枝干节点和叶子节点统一当作一种对象处理呢?这就需要用到组合模式了. 转

java/android 设计模式学习笔记（9）---代理模式

这篇博客我们来介绍一下代理模式(Proxy Pattern),代理模式也成为委托模式,是一个非常重要的设计模式,不少设计模式也都会有代理模式的影子.代理在我们日常生活中也很常见,比如上网时连接的代理服务器地址,更比如我们平时租房子,将找房子的过程代理给中介等等,都是代理模式在日常生活中的使用例子. 代理模式中的代理对象能够连接任何事物:一个网络连接,一个占用很多内存的大对象,一个文件,或者是一些复制起来代价很高甚至根本不可能复制的一些资源.总之,代理是一个由客户端调用去访问幕后真正服务的包装对象

java/android 设计模式学习笔记（16）---命令模式

这篇博客我们来介绍一下命令模式(Command Pattern),它是行为型设计模式之一.命令模式相对于其他的设计模式更为灵活多变,我们接触比较多的命令模式个例无非就是程序菜单命令,如在操作系统中,我们点击关机命令,系统就会执行一系列的操作,如先是暂停处理事件,保存系统的一些配置,然后结束程序进程,最后调用内核命令关闭计算机等,对于这一系列的命令,用户不用去管,用户只需点击系统的关机按钮即可完成如上一系列的命令.而我们的命令模式其实也与之相同,将一系列的方法调用封装,用户只需调用一个方法执行,那

java/android 设计模式学习笔记（4）---抽象工厂模式

再来介绍一下抽象工厂模式(Abstact Factory Pattern),也是创建型模式之一,上篇博客主要介绍了工厂方法模式.抽象工厂模式和工厂方法模式稍有区别.工厂方法模式中工厂类生产出来的产品都是具体的,也就是说每个工厂都会生产某一种具体的产品,但是如果工厂类中所生产出来的产品是多种多样的,工厂方法模式也就不再适用了,就要使用抽象工厂模式了. 抽象工厂模式的起源或者最早的应用,是对不同操作系统的图形化解决方案,比如在不同操作系统中的按钮和文字框的不同处理,展示效果也不一样,对于每一个操作系