设计模式篇（二）——建造者模式

最新推荐文章于 2024-10-17 09:45:23 发布
最新推荐文章于 2024-10-17 09:45:23 发布
阅读量246 收藏 2
点赞数
分类专栏： # 设计模式篇 文章标签： 设计模式 android
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/catzifeng/article/details/105009405
版权

文章目录

一、简介

建造者模式（Builder Pattern） 也比较常见，该模式与单例模式同属于创建型模式，当我们需要构建一个复杂的对象，就可以利用该模式，达到精简优化的效果。

定义：建造者模式将复杂对象的构造与其表示分离，以便同一个构造过程可以创建不同的表示。

使用场景：构建复杂的对象，在 Android 中有 Notification 和 Dialog 等。

实现要素：

  1. 将所有的构造相关的方法，置于 Builder 中。
  2. 通过建造者模式获得的对象，你只能使用它，而不能修改其属性。

通俗的讲：一个类的构造，有 setter 和 getter ，使这两种类型的方法分开，创建一个 Builder 角色，承担类的 setter ，而 getter 则还是保留与原本类中。

二、实现

我们只需要关注建造者模式的精髓，在各种项目中，你完全可以发挥自己的小技巧，来实现各种不同的变种，事实上其他的设计模式也是类似的。

1、角色介绍
  • Product 需要构建的具体类。
  • Builder<Abstract> 这是个抽象基类，可以是抽象类也可以是接口，用于定义 Product 的构建方法。
  • Concrete Builder 是 Builder 的具体实现类，你可以创建多个实现类，来达到创建不同表示的目的。
  • Director 通过该类，你可以实现具体某一个 Concrete Builder，从而来得到一个具体的 Product。
2、普通类实现
class Pc {

    private var mName: String? = null
    private var mCpu: String? = null
    private var mRomSize: Int? = null

    fun setName(name: String) {
        this.mName = name
    }

    fun setCpu(cpu: String) {
        this.mCpu = cpu
    }

    fun setRomSize(romSize: Int) {
        this.mRomSize = romSize
    }

    fun getName():String{
        return mName?:"没名字"
    }

    fun getCpu():String{
        return mCpu?:"没名字"
    }

    fun getRomSize():Int{
        return mRomSize?:0
    }
}


fun main() {
    val pc = Pc()
    pc.setName("Surface Book")
    pc.setCpu("Intel i7")
    pc.setRomSize(512)

    print(pc.getName())
}

如代码所见，我们构建一个 Pc 对象，需要直接操控 Pc 对象，通过其方法。

3、通过建造者模式实现

我们先看一个UML图，然后再结合代码，会更清楚整体的框架。
UML

//这是 Product
class Pc {

    private var mName: String? = null
    private var mCpu: String? = null
    private var mRomSize: Int? = null

    fun setName(name: String) {
        this.mName = name
    }

    fun setCpu(cpu: String) {
        this.mCpu = cpu
    }

    fun setRomSize(romSize: Int) {
        this.mRomSize = romSize
    }

    fun getName():String{
        return mName?:"没名字"
    }

    fun getCpu():String{
        return mCpu?:"没名字"
    }

    fun getRomSize():Int{
        return mRomSize?:0
    }
}

//这是 Builder 接口
interface PcBuilder{
    fun setName()
    fun setCpu()
    fun setRomSize()
    fun createPc():Pc
}

//这是具体的 Builder
class SurfaceBookBuilder: PcBuilder{

    private var pc:Pc

    init {
        pc = Pc()
    }
    
    override fun setName() {
        pc.setName("Surface Book")
    }

    override fun setCpu() {
        pc.setCpu("Intel i7")
    }

    override fun setRomSize() {
        pc.setRomSize(512)
    }

    override fun createPc(): Pc {
        return pc
    }
}

//这是具体的 Builder
class MacBookBuilder : PcBuilder{

    private var pc:Pc

    init {
        pc = Pc()
    }

    override fun setName() {
        pc.setName("MacBook")
    }

    override fun setCpu() {
        pc.setCpu("Intel i7")
    }

    override fun setRomSize() {
        pc.setRomSize(1024)
    }

    override fun createPc(): Pc {
        return pc
    }
}

//这是组装类
class PcDirector(private val mBuilder: PcBuilder){

    fun getPc(): Pc {
        constructPc()
        return mBuilder.createPc()
    }

    private fun constructPc(){
        mBuilder.setName()
        mBuilder.setCpu()
        mBuilder.setRomSize()
    }
}


fun main() {
    //创建一个 SurfaceBook
    val pcBuilder = SurfaceBookBuilder()
    val surfaceBook = PcDirector(pcBuilder).getPc()
	//创建一个 MacBook
	val pcBuilder2 = MacBookBuilder()
    val macBook= PcDirector(pcBuilder2).getPc()
}

问题分析：虽然我们都创建了各个角色，也最终实现了效果，
但是，回到建造者模式的本质：将构建与表示分离。我们真的做到了分离吗？
答案是：No。因为我们还是能够通过创建好的对象来继续调用其 setter，例如surfaceBook.setName()，所以这是一个失败的建造者模式。

4、修正

为了使得我们不能再继续调用surfaceBook.setName()，那该如何解决这个问题呢？
答：将 Product 类的 setter 方法私有化。

但是私有化后，我们的 Builder 类却无法访问其 setter 方法，那又怎么办呢？
答：使 Builder 类成为Product 的内部类。

修改后的代码：

interface PcBuilder{
    fun setName()
    fun setCpu()
    fun setRomSize()
    fun createPc():Pc
}

class Pc {

    private var mName: String? = null
    private var mCpu: String? = null
    private var mRomSize: Int? = null
	
    private fun setName(name: String) {
        this.mName = name
    }

    private fun setCpu(cpu: String) {
        this.mCpu = cpu
    }

    private fun setRomSize(romSize: Int) {
        this.mRomSize = romSize
    }

    fun getName():String{
        return mName?:"没名字"
    }

    fun getCpu():String{
        return mCpu?:"没名字"
    }

    fun getRomSize():Int{
        return mRomSize?:0
    }

    class SurfaceBookBuilder : PcBuilder{

        private var pc:Pc

        init {
            pc = Pc()
        }

        override fun setName() {
            pc.setName("Surface Book")
        }

        override fun setCpu() {
            pc.setCpu("Intel i7")
        }

        override fun setRomSize() {
            pc.setRomSize(512)
        }

        override fun createPc(): Pc {
            return pc
        }
    }

    class MacBookBuilder : PcBuilder{

        private var pc:Pc

        init {
            pc = Pc()
        }

        override fun setName() {
            pc.setName("MacBook Air 2020")
        }

        override fun setCpu() {
            pc.setCpu("Intel i7")
        }

        override fun setRomSize() {
            pc.setRomSize(1024)
        }

        override fun createPc(): Pc {
            return pc
        }
    }
}


class PcDirector(private val mBuilder: PcBuilder){

    fun getPc(): Pc {
        constructPc()
        return mBuilder.createPc()
    }

    private fun constructPc(){
        mBuilder.setName()
        mBuilder.setCpu()
        mBuilder.setRomSize()
    }
}


fun main() {

    val pcBuilder = Pc.SurfaceBookBuilder()
    val surfaceBook = PcDirector(pcBuilder).getPc()
}

我们将 Pc 类中所有的 setter 都设置了 private，那么除了本类能够访问，其内部类也可以访问。
注意，此处建议使用静态内部类，Kotlin 中不作任何类的修饰词，默认相当于 Java 的静态内部内，使用 Java 记住给类添加 static 关键词。

其后我们获得的 surfaceBook 对象，就无法使用 setter 方法了。

5、常见变种

我们发现，两个 Builder 子类，其实现的方法都是可以动态实现的，且方法是被 Director 调用的，那么如果我们在 Director 动态实现的话，就完全可以省略多个 Builder子类，但是随之而来的问题就是，Dirctor 会变得臃肿，那么解决该问题的方法就是，直接省略 Dirctor 角色。

且在实现的过程中，如果我们在 Builder 类的每一个 setter 方法中，返回 this ，那么就可以使用链式的效果。最后的代码变成：

class Pc {

    private var mName: String? = null
    private var mCpu: String? = null
    private var mRomSize: Int? = null

    private fun setName(name: String) {
        this.mName = name
    }

    private fun setCpu(cpu: String) {
        this.mCpu = cpu
    }

    private fun setRomSize(romSize: Int) {
        this.mRomSize = romSize
    }

    fun printInfo() {
        print("笔记本的名字：$mName ,Cpu型号为：$mCpu")
    }

    class Builder {

        private var pc: Pc

        init {
            pc = Pc()
        }

        fun setName(name: String): Builder {
            pc.setName(name)
            return this
        }

        fun setCpu(cpu: String): Builder {
            pc.setCpu(cpu)
            return this
        }

        fun setRomSize(size: Int): Builder {
            pc.setRomSize(512)
            return this
        }

        fun createPc(): Pc {
            return pc
        }
    }

}


fun main() {
    
    val surfaceBook = Pc.Builder()
        .setName("SurfaceBook")
        .setCpu("SurfaceBook")
        .setRomSize(512)
        .createPc()

    surfaceBook.printInto()
}

三、相关源码

以 OkHttp3 的源码为例，我们先看看创建 OkHttpClient 实例的过程：

val okHttpClient = OkHttpClient.Builder()
            .callTimeout(1000,TimeUnit.SECONDS)
            .writeTimeout(1000,TimeUnit.SECONDS)
            ... ... //添加其他设置
            .build()

先看看整体的结构：

open class OkHttpClient internal constructor(builder: Builder) {

	... ...
	
	class Builder constructor() {
		... ...
	}
}

再看看 Builder 类中某个具体的方法，以 callTimeout() 为例，再看看最后的build()方法：

class Builder constructor() {
	... ...
	internal var callTimeout = 0
	
	... ...
	fun callTimeout(timeout: Long, unit: TimeUnit) = apply {
    	callTimeout = checkDuration("timeout", timeout, unit)
  	}

	fun build(): OkHttpClient = OkHttpClient(this)
}

我们看到，build() 方法最后是直接返回一个 new 的 OkHttpClient，并且将自身作为其构造函数的参数，那么我们返回 OkHttpClient 类中，看看其实现：

open class OkHttpClient internal constructor(builder: Builder){
	... ...
	val callTimeoutMillis: Int = builder.callTimeout
	... ...
}

最后，是将 Builder 中设置的属性，再次赋值到了 OkHttpClient 中。

不仅如此，OkHttpClient 还实现了 new Builder()的方法，用于在已有实例的基础上，重新设置其属性，具体的源码自行观阅去吧~
收工

四、小结

我们一定要明白建造者模式的精髓，那就是构建与表示分离！只要你基于这个原则，你想怎么玩就怎么玩~

catzifeng
关注
专栏目录
大话设计模式C++版——建造者模式
m0_70960708的博客
10-07 95
我们在开发过程中经常会碰到一种情况，一个类实现了一组底层的基本功能，但实现一个高级功能时需要把某些基本功能组合起来调用，这时采用建造者模式就能保证调用过程顺序一致且无遗漏，同时调用者调用也很简单（如炒菜就只需调用Cook()函数即可，而不用去关心每一个具体细节）。这个时候就需要用到建造者模式来规范炒菜的过程，来保证每一道菜都会经历加油、放食物、放盐、放味精这4道基本的工序，同时保证每道工序不会重复。//为了保证所有的子类能够按照指定顺序依次实现完整的建造过程，而不会忘记某一个过程的调用（如忘了放盐）
93 | Python 设计模式 —— 建造者模式
微信号：RunsenLiu
08-08 1298
建造者模式是一种创建型设计模式，它解决了创建复杂对象的问题。在建造者模式中，将一个复杂对象的构建过程和表示分离，使得构建过程可以创建不同的表示。这样，同样的构建过程可以创建不同类型或配置的对象，使得代码更加灵活和易于维护。当需要构建的对象有多个组成部分，且构建过程相对复杂。当希望创建不同类型或配置的对象，但又不希望客户端直接与具体构建过程耦合。建造者模式是一种创建型设计模式，它通过将复杂对象的构建过程与表示分离，使得构建过程可以创建不同的表示。
设计模式——建造者
热门推荐
hello_haozi的专栏
08-25 1万+
最近的心得，我发现学一门设计模式，不管你是否能立刻理解它，第一最要紧的是要记住两个东西。1、它是属于什么范畴的设计模式。2、记住UML图。这两个是打开这个设计模式之门的金钥匙！为什么这么讲？因为刚刚学新的设计模式，如果一味的埋头在文字中，思想中，代码编写的例子中，如果你这个设计模式又不是看的很懂，实在是会让人晕头转向看的吐血身亡。结果在身亡前，你都不知道这个设计模式干什么用，也不知该怎么去写。心得
用代码和UML图化解设计模式之《创建者模式》
wintree的专栏
10-24 2182
今天学习了建造者模式，目前较为复杂的一个模式之一。但是思考起来就觉得她很像抽象工厂的生产者模式。   但是比生产者多了一个导演着的身份，这个指挥着建造者去生产谁。。。   所以，这个模式还是挺有意思的。直接上UML图。   我们生产两种商品，两种商品是有厂家决定，商品只决定具有哪些。因此，这时候是有生产者说了算。   但是还有一个更高级的指挥者，那就是 导演类。安排生产。
Java静态类 Builder（建造者）模式
T的专栏
04-03 4505
在Java世界里，经常被提到静态这个概念，static作为静态成员变量和成员函数的修饰符，意味着它为该类的所有实例所共享，也就是说当某个类的实例修改了该静态成员变量，其修改值为该类的其它所有实例所见。最近一个项目里频繁用到static修饰的内部类，再读了一下《Effective Java》才明白为什么会用static来修饰一个内部类也就是本文的中心——静态类。 如果一个类要被声明为stat...
建造者模式
weixin_34221276的博客
07-29 118
《大话设计模式》阅读笔记和总结。原书是C#编写的，本人用Java实现了一遍，包括每种设计模式的UML图实现和示例代码实现。 目录：设计模式 Github地址：DesignPattern 说明 定义：建造者模式（Builder），将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。 U...
Java 设计模式——建造者模式
代码星辰的博客
11-25 919
本文介绍了建造者模式的相关知识。
设计模式——建造者模式
weixin_46073538的博客
07-10 1177
建造者模式(Builder Pattern)又叫生成器模式，是一种对象构建模式。它可以将复杂对象的建造过程抽象出来(抽象类别)，使这个抽象过程的不同实现方法可以构造出不同表现(属性)的对象。建造者模式 是一步一步创建一个复杂的对象，它允许用户只通过指定复杂对象的类型和内容就可以构建它们.用户不需要知道内部的具体构建细节。
java设计模式（五）——建造者模式
print_out的博客
07-03 252
建造者模式创建型模式的一种，他可以将复杂对象的建造过程抽象出来，使这个抽象过程的不同实现方法可以构造出不同表现的对象。使用场景：当一个类的构造参数有多个，而且这些参数有些是可选的参数，就可以考虑使用建造者模式。//大小，必须//颜色，必须//logo，可选//标签，可选大小（size）颜色（color）是必须的，logo（logo）、标签（tip）是可选的。在实例化对象时size和color是必填参数，而logo和tip是可选参数，通常有两种方式构建1、折叠构造函数模式。
设计模式-构建者模式
weixin_33645586的博客
08-23 450
意图 构造者模式（建造者模式、生成器模式）是一种创建型设计模式， 使你能够分步骤创建复杂对象。 该模式允许你使用相同的创建代码生成不同类型和形式的对象。 问题 假设有这样一个复杂对象， 在对其进行构造时需要对诸多成员变量和嵌套对象进行繁复的初始化工作。 这些初始化代码通常深藏于一个包含众多参数且让人基本看不懂的构造函数中； 甚至还有更糟糕的情况， 那就是这些代码散落在客户端代码的多个位置。 例如， 我们来思考如何创建一个 房屋House对象。 建造一栋简单的房屋， 首先你需要建造四面墙和地板， 安装房门和
建造者模式（Builder）及其应用
徐公，微信公众号同名
08-04 8346
建造者模式（Builder）及其应用其实建造者模式在我们平时写项目的时候我们经常看到，大部分人没仔细观察或者不熟悉建造者模式，才忽略了它，在我们常用的ImageLoader和Rxjava里面其实都运用了建造者模式本篇博客主要讲解一下几个问题 1. 什么是建造者模式 2. 建造者模式的应用场景及小Demo 3. 建造者模式在Android源码中的体现 4. 建造者模式在常见的开源框架中Imag
设计模式----建造者模式UML和实现代码
weixin_33882443的博客
11-19 976
2019独角兽企业重金招聘Python工程师标准>>> ...
23种设计模式模式详解 Java UML类图小知识（一）
rickey17的博客
04-16 8041
23种设计模式模式详解 Java UML类图小知识（一）设计模式（Design pattern）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。 使用设计模式的好处：代码的可重用性、可扩展性，可阅读性，保证代码的可靠。（代码要优雅）关于相关源码可以在GitHub上下载： https://github.com/rickey17/design 设计模式的6大原则 设计模式分类 创
23种设计模式具体实现方法
晴山の博客
10-16 656
前期疑问：适配器模式的优点主要包括：（1）提高类的透明性和复用性： 适配器模式可以让类在现有的基础上进行复用，而不需要做出任何改变，这有助于避免大规模改写现有代码。（2）解耦目标类和适配器类： 通过使用适配器模式，目标类和适配器类可以实现解耦，从而提高程序的扩展性。这符合开闭原则，即对扩展开放，对修改关闭。（3）更好的扩展性： 在实现适配器功能的时候，可以调用自己开发的功能，从而自然地扩展系统的功能。（4）灵活性好： 适配器并没有影响原有功能，如果不想使用，可以直接删除。
设计模式02-桥接模式(Java)
XYX_888的博客
10-13 679
它是用组合关系代替继承关系来实现，从而降低了抽象和实现这两个可变维度的耦合度。在使用关联关系是，及在抽象类引入实现类接口时可能会出现不适配的情况，这是可以用适配器类型将其转换成抽象类可以适配的类进行关联。扩展抽象化角色 ：是抽象化角色的子类，实现父类中的业务方法， 并通过组合关系调用实现化角色中的业务方法。实现化角色 ：定义实现化角色的接口，供扩展抽象化角色调用。抽象化角色 ：定义抽象类，并包含一个对实现化对象的引用。具体实现化角色 ：给出实现化角色接口的具体实现。实现了对抽象和实现之间的解耦。
【GeekBand】C++设计模式笔记8_Factory Method_工厂方法
qq_38154295的博客
10-13 497
【GeekBand】C++设计模式笔记8_Factory Method_工厂方法
Java设计模式梳理：行为型模式（策略，观察者等）
最新发布
helloworld工程师的博客
10-17 1166
行为型模式部分介绍了策略模式、观察者模式、责任链模式、模板方法模式和状态模式，其实，经典的行为型模式还包括备忘录模式、命令模式等，但是它们的使用场景比较有限，而且本文篇幅也挺大了，我就不进行介绍了。学习设计模式的目的是为了让我们的代码更加的优雅、易维护、易扩展。这次整理这篇文章，让我重新审视了一下各个设计模式，对我自己而言收获还是挺大的。我想，文章的最大收益者一般都是作者本人，为了写一篇文章，需要巩固自己的知识，需要寻找各种资料，而且，自己写过的才最容易记住，也算是我给读者的建议吧。（全文完）
Java设计模式10 - 观察者模式
Java_fenxiang的博客
10-14 811
观察者模式观察者模式也叫作发布-订阅模式，也就是事件监听机制。观察者模式定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象，这个主题对象在状态上发生变化时，会通知所有观察者对象，使他们能够自动更新自己。观察者模式的结构一个软件系统常常要求在某一个对象状态发生变化时，某些其他的对象作出相应的改变。能做到这一点...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值