zoukankan      html  css  js  c++  java
  • 设计模式建造者模式

    角色


    建造者故名思想,就是建房子的人,是来自建筑工程领域的的概念,其中包含三种主要角色:

    • 建造者(Builder):不同种类的工人,如打地基的,建房梁的,室内装修的等;
    • 具体的建造者(ConcreteBuilder):每个工种对应的具体的工人;
    • 指挥者(Director):工程队总指挥,包工头,指挥具体的建造者建房子;
    • 具体产品(Product):最终建成的房子。

    定义


    建造者模式是将一个复杂的对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示。创建者模式隐藏了复杂对象的创建过程,它把复杂对象的创建过程加以抽象,通过子类继承或者重载的方式,动态的创建复杂的、具有复合属性的对象。

    案例


    下面将通过一个小案例来解释说明什么建造者模式。

    简化需求

    假设需要制造一个手机,手机包括CPU,内存,屏幕等几个部分,而CPU,内存,屏幕配置不同又有高端,低端之分。要求手机配置可以灵活搭配。

    初始版UML

    该版本直接在在需要的时候通过new创建不同规格的CPU,内存,屏幕等对象。

    优点

    简单,并且配置可灵活搭配

    缺点

    • 面向了实现编程,用户需要知道太多的创建细节

    工厂方法改造

    基于上述原因,我们通过工厂方法改造,屏蔽具体配件的创建细节。

    优点

    • 屏蔽了配件的创造细节
    • 配置可灵活搭配

    缺点

    • 复杂度急剧增大,类爆炸
    • 把配件的组装交给手机类(Phone)处理不合理
    • 没有屏蔽手机创造细节

    抽象工厂+简单工厂改造

    为了解决类爆炸的问题,我们合并配件工厂类,由一个抽象工厂创建相关配件,再由简单工厂组装生产手机成品。

    简化UML(标准版本)

    由于无论是CPU、内存还是屏幕都属于手机的一部分,因此整个产品还是手机本身,由此,可简化上述UML图,并抽象得到下图:

    优点

    • 一定程度上,消除了类爆炸问题
    • 职责分离,由单独一个生产线组装手机

    缺点

    • 配件配置变得固定了,不能随意组合
    • 对大多数场景依然过于复杂,比如,未必每一个配置的手机都需要一个生产线,组装手机也未必需要一个单独的生产线。

    进一步简化

    很多场景中并没有指挥者,或者说指挥者就是建造者本身,因此,建造者模式可进一步简化为如下结构:

    再进一步改造

    同样的,大多数情况一个建造者只会有一个实现子类,因此,还可用进一步简化,这样可以使用委托对需要建造的对象进行灵活的配置。

    简化UML(简化版本,最常用)

    优点

    简单,灵活,代码优雅

    缺点

    用户使用成本相对较高,需要使用者自己配置内部参数。

    总结


    建造者模式通常用于动态的创建复杂的、具有复合属性的对象。在.Net Core也存在大量的建造者模式的使用,例如,StringBuilderHostBuilderIHostBuilderIWebHostBuilderConfigurationBuilder等,有兴趣的可以学习下。

    源码链接

  • 相关阅读:
    source is null for getProperty(null, "cpmodel")异常结局
    insert时报Cannot add or update a child row: a foreign key constraint fails (`yanchangzichan`.`productstatusrecord`, CONSTRAINT `p_cu` FOREIGN KEY (`cid`) REFERENCES `customer` (`cid`))错误
    Python流程控制
    Python运算符
    Python字符串格式化输出
    Python数据强制类型转换
    Python数据类型
    Python input函数使用
    Python print函数使用
    Python变量
  • 原文地址:https://www.cnblogs.com/FindTheWay/p/13559301.html
Copyright © 2011-2022 走看看