西安做网站公司哪家比较好,大学生网络营销策划书模板,河南企业网站制作,上海知名进出口贸易公司在前面几篇文章中#xff0c;已经讲解了单例模式、工厂方法模式、抽象工厂模式#xff0c;创建型还剩下一个比较重要的模式-建造者模式。在理解该模式之前#xff0c;我还是希望重申设计模式的初衷#xff0c;即为解决一些问题而提供的优良方案。学习设计模式遗忘其初衷已经讲解了单例模式、工厂方法模式、抽象工厂模式创建型还剩下一个比较重要的模式-建造者模式。在理解该模式之前我还是希望重申设计模式的初衷即为解决一些问题而提供的优良方案。学习设计模式遗忘其初衷注定无法理解其真正的深刻内涵。从创建型模式的名称上来看这些都是为了解决创建对象相关的问题。单例模式解决了如何创建唯一对象的问题工厂方法模式解决了对象创建过程的封装问题抽象工厂模式解决了创建多个相关联对象的问题那么不知道你之前是否有思考过建造者模式是要解决什么问题吗我相信很多人可能没有思考而直接用老一套去学习该模式最终就是不理解、记不住、用不会
一、建造者模式概念理解
建造者模式又称生成器模式在大部分参考资料中都公认的定义为 将一个复杂对象的构建与它的表示分离使得同样的构建过程可以创建不同的表示。 我不知道你们能不能理解这个很抽象的定义起初我是不太能理解。我似乎从“分离”上能看出是要解耦至于“构建”、“表示”这两个词本身就有模糊的感觉。实际上这里的“构建”可以理解为“里子”“表示”可以理解为“面子”“同样的构建过程可以创建不同的表示”就是里子和多个面子需要解耦如同一个人可以拥有很多面具以示人。意即你还是你但是外人看到的可以有多个。 “构建”指的就是里子。每一个可由外界创建对象的类都会提供一个或多个构造函数或为有参构造亦或为无参构造。对象的正规创建最常用的方式通过new关键字及构造方法Constructor。然而实际上对象的构建过程并不止步于此。对象的本质是类信息(包括属性、方法)数据前者是编译后就固定不变的后者数据是运行时改变的因此对象的构建过程应从分配内存开始直到对象数据初始化结束。对象的初始化除了调用Constructor方法之外还有Setter方法也会经常用于初始化对象数据注这里Setter方法不仅仅指的是get\set方法。因此对象的构建过程本质上是类构造函数-ConstructorSetter方法。我们通常会使用这二者协同初始化对象数据并获得对象但是这里面会不会存在问题呢? 可实例化类会提供多个构造函数提供给外界用于创建对象。构造函数可能的复杂性包括两个部分一个是入参一个是具体逻辑。后者可以通过工厂方法模式进行封装那前者怎么办即若对象的创建需要很多外界输入参数其中包括必要参数或非必要参数这种情况下我们在一些源码或业务代码中会看到类中会提供很多个构造方法不同构造方法通过重载的方式处理参数的差异性使用方根据需要选择不同的构造方法。那如果参数再多一些呢你无法判断使用方想传入哪些参数或者不传入哪些参数来构建对象。还有一种情况即使类的构建过程需要通过对应的内部配置类进行构建。你只提供内部相关复杂对象作为入参的有参构造我根本不了解这个入参如何办举例你提供了Configure内部类作为创建会话对象的有参构造保证了迪米特原则但是我这边数据可能是XML类型配置、YAML类型配置文件等是否我需要解决这些文件解析为Configure内部类对象才能使用你的构造方法呢这些都是问题问题的根因就是你的类创建对象过程里子和面子耦合太严重一个构造对象提供一个面子。 对于构造方法参数数量问题有的同学会说那我就把必选参数留在构造方法可选参数使用Setter方法。似乎是能够解决一部分问题但是Setter方法可能会使得对象的构建逻辑分散在各处增加了使用不完整对象的风险。【因此建造者模式是不建议调用端直接使用对象的Setter方法必须封装起来】 如何解耦呢能否将构建对象所需数据面子和构造函数中的逻辑里子拆分。我们讲过解决耦合问题的究极好办法就是加一层即Builder层。让Builder来充当这个面子Builder负责提供给外界并预处理外界数据转换为内部Constructor所需要的数据然后由Builder来调用Constructor来返回对象。这样的解耦使得Constructor仅专注于内部构建逻辑而外界所需要的面子均由Builder来负责如此设计既满足业务需要也满足单一职责原则。 概念总结
建造者模式主要解决创建对象时对象的创建过程与创建的所需数据表示的严重耦合性问题Constructor构造方法在非必要参数多时无法满足调用方的需求且在复杂构造参数内部配置类时增加调用方创建难度。Setter方法也是对象构建过程的一部分但是可能会误使用不成熟对象通过职责拆分的方法解耦对象构建过程及其表示。Builder负责承接调用方可能赋值的数据并转换为类对象创建的内部参数需要。目标对象的类仅关注自身功能的实现。【即Builder出去跑业务伺候甲方的。Construstor做好自己本职工作】
二、应用实践
上一章节限于个人水平有限理解角度与主流理解不完全契合也会存在让大家误解的地方。因此这个章节就通过具体的示例来说说我的想法比较不同方案的优劣达到理解建造者模式的目的。在其他参考资料中给出的案例和建造者解决方案我认为虽容易看懂但不易理解且难以投入实际使用可能还存在一些问题。下面我会通过一个简单的案例一步步分析为什么常规的建造者模式大家几乎都不会使用到。
2.1 基本案例
案例的背景就以大家熟悉的“电脑”对象创建为例想象以下创建一个电脑对象应该具备哪些东西数据呢大概会有CPU中央处理器、内存、硬盘、显卡、显示器、键盘、鼠标、声卡、网卡、光驱等。所以创建一个电脑对象可能会需要很多种数据但是根据用户的需求不同需要创建的电脑对象可能也存在差异性。如 ① 我仅需要电脑用于跑程序那我只需要【CPU、内存、硬盘】去创建电脑对象 ② 我要跑深度学习那我除了以上组件数据之外还需要好的【显卡】 ③ 我要打游戏那我除了以上组件数据之外还需要好的【显示器、键盘、鼠标、声卡、网卡】等 ④ 我要看DVD那我就得需要【光驱】了。 … 你看看多头疼根据调用方使用场景不同电脑对象的所需组件也有不同。难道你要遍历所有场景给出不同的构造方法很明显这种方案不太现实。但如果你仔细发现就可以看到对象的创建是可以区分必要组件和非必要组件的。在这个例子中不论用户的需求是啥都需要有【CPU、内存、硬盘】才能创建电脑。那是否电脑类仅提供必要组件的构造方法非必要组件由Setter方法来负责呢这已经是个很好的方案大部分的业务开发中可能都会使用这个方案。但设计模式不会止步于此存在两个疑问1Setter方案存在什么问题2有没有更好的方案解决 Setter方案存在两个问题第一个问题前面也提到了对象数据初始化逻辑分散在各处增加了使用不完整对象的风险。第二个问题是使用方不清楚Setter方法具体含义是仅用于对象初始化类似于Construstor还是用于对象数据运行时修改类似于其余普通函数即责任不明。 为解决这个问题我们前面提出中间添加builder层由Builder来负责封装对象构建的多种表示的差异性。示例代码如类图如下 ① “电脑”对象类
public class Computer {private Object cpu;private Object memory;private Object hardDisk;private Object graphicsCard;private Object monitor;private Object keyboard;private Object mouse;private Object soundCard;private Object networkCard;private Object opticalDrive;public Computer(Object cpu, Object memory, Object hardDisk) {this.cpu cpu;this.memory memory;this.hardDisk hardDisk;}public void setGraphicsCard(Object graphicsCard) {this.graphicsCard graphicsCard;}public void setMemory(Object memory) {this.memory memory;}// 其他可选属性set方法省略...public void doSomething() {// ...}
}② Builder接口
public interface ComputerBuilder {void setGraphicsCard(Object graphicsCard);void setMonitor(Object monitor);void setKeyboard(Object keyboard);void setMouse(Object mouse);void setSoundCard(Object soundCard);void setNetworkCard(Object networkCard);void setOpticalDrive(Object opticalDrive);Computer buildComputer(Object cpu, Object memory, Object hardDisk);Computer buildDLComputer(Object cpu, Object memory, Object hardDisk, Object graphicsCard);
}③ Builder具体实现类
public class ConcreteComputerBuilder implements ComputerBuilder{private Object graphicsCard;private Object monitor;private Object keyboard;private Object mouse;private Object soundCard;private Object networkCard;private Object opticalDrive;Overridepublic void setGraphicsCard(Object graphicsCard) {this.graphicsCard graphicsCard;}Overridepublic void setMonitor(Object monitor) {this.monitor monitor;}Overridepublic void setKeyboard(Object keyboard) {this.keyboard keyboard;}Overridepublic void setMouse(Object mouse) {this.mouse mouse;}Overridepublic void setSoundCard(Object soundCard) {this.soundCard soundCard;}Overridepublic void setNetworkCard(Object networkCard) {this.networkCard networkCard;}Overridepublic void setOpticalDrive(Object opticalDrive) {this.opticalDrive opticalDrive;}Overridepublic Computer buildComputer(Object cpu, Object memory, Object hardDisk) {// ...这里省略必要参数的校验逻辑Computer ins new Computer(cpu, memory, hardDisk);if(this.graphicsCard ! null) {ins.setGraphicsCard(this.graphicsCard);}// ... 省略其余可选参数的处理逻辑return ins;}Overridepublic Computer buildDLComputer(Object cpu, Object memory, Object hardDisk, Object graphicsCard) {// ...这里省略必要参数的校验逻辑Computer ins new Computer(cpu, memory, hardDisk);if(graphicsCard null) {throw new RuntimeException(缺少显卡组件无法创建深度学习机器);}ins.setGraphicsCard(this.graphicsCard);// ... 省略其余可选参数的处理逻辑return ins;}
}完整的代码如上类图中使用SetXXX省略了很多Set方法。这种就属于建造者模式调用方可通过ComputerBuilder来实现获取Computer对象而在ComputerBuilder中对于可选参数的处理通过封装在了buildXXX方法中并且提供了多种类型的builder方法供调用方使用。因此这样就实现了对象的构建与它的表示代码中给出了2种表示还可以更多解耦表示虽不同但是实际上都是通过同一个Constructor来创建对象的。 在一些参考资料中还给出了Director类Director翻译为导演类意即就是将多种表示如普通电脑、深度学习电脑、打游戏电脑等预先封装到Director中供调用方使用调用方不再感知setXXX设置组件数据的过程了。 我认为这种封装会造成类的急速膨胀而且效果不好。你根本无法预知调用方会有什么样的场景Director类也无法彻底解决问题。如上例在Builder通过不同的方法返回不同对象也有同样效果且没有问题。 目前Setter方法问题通过这种方法已经很好解决了很多相关参考资料也到此结束了但我认为建造者模式的理解尚不能止步因为还有遗漏的地方。之前的思考思路是对象初始化Constructor构造函数可能会存在很多可选参数不可能全部提供对应的构造方法。然后我们分析了使用Setter方法解决可选参数的问题但是Setter方法的使用增加了使用不成熟对象的风险。之后我们增加了builder层封装处理了Setter方法然后创建对象。 可以看出我们之前只是从构造函数数量问题上思考但是这很难让我们理解并使用建造者模式。为什么这么说呢因为我们在平时开发中几乎不会碰到这种情况。在大部分的开发场景下当函数形参数量大于7时我们就会单独封装为一个类因此我们很少会碰见要处理参数数量上的问题大部分情况下我们是要处理类型问题。
2.2 理解“表示”
不同的表示就是指用于初始化对象的数据不确定由调用方指定包括数量不确定以及类型不确定两个方面。数量不确定可通过上一小节的方案解决但需要注意的是当函数形参数量大于7时我们就会单独封装为一个类这也会转换为类型不确定。类型不确定是啥意思呢在第一章节内我们提到大部分的复杂对象由于其所需数据多一般创建对象都是通过其内部配置类创建的你不能要求所有的调用方都必须了解这个内部配置类才能创建对象。 说起来有些许抽象就以前一小节案例来说。创建一个深度学习机器肯定是需要显卡组件参数细想这里会存在一个我们经常忽略的问题就是显卡对于“创建电脑”来说会很复杂。创建电脑的过程你必须考虑显卡的接口、频率、功率等信息这就意味着显卡的类型不仅仅是个简单Object类而是一个相对复杂的参数类定义为类GraphicsCard。那问题来了调用端为了意图创建一个电脑还需要先创建一个GraphicsCard对象吗那其他组件呢太麻烦啦调用方能否只传输一个String表示显卡的型号呢。继续分析电脑对象会提供String类型显卡参数的构造方法吗明显不会否则电脑对象内部就得处理String到GraphicsCard对象的创建过程了电脑类的职责不再单一这就是构建过程和表示耦合导致的结果。因此将String到GraphicsCard对象的过程就可以由Builder承担了这样既满足了调用方对于不同表示的需求也保证了目标对象构建过程的职责清晰。 根据此响应代码类图如下代码简单不再提供具体代码 从类图中看出Builder提供了接受String类型数据来负责处理显卡参数类型问题Computer还是仅负责自己内部的逻辑即可外面的一切由Builder这个跑业务的给摆平。这么一看建造者模式理解起来就豁然开朗调用方要创建对象但是无法提供创建对象的条件那就上Builder来处理这其中的GAP即可。这就达到了外界可以使用多种方式表示通过Builder创建目标对象 而实际Computer创建对象的动作可能还是同一套逻辑Constructor。 数量不确定 远没有 类型不确定 带来的问题严重。如果仅仅是数量问题使用Setter方法方案即可使用Builder封装Setter稍微有点大材小用了。但是类型问题就必须得使用Builder来解决了。 大部分的 数量问题 也都可能转换为 类型问题。当参数数量很多时都会考虑将这些参数封装起来比如Configure类。目标对象的创建仅通过Confugure对象数据来创建而Builder就负责将外部数据转换为Configure对象。 这是普遍的做法说到这你是否觉得上文的两个类图有哪里让人不适的地方对属性太多啦目标对象属性一套数据Builder也跟着一套数据代码重复且可读性会差。解决办法就是封装要么使用Configure类要么使用枚举或其他都行。 大部分情况下我们是要处理类型问题下面我们简单看下Mybatis中用于创建SqlSessionFactory对象的建造者模式是怎么应用的下面给出SqlSessionFactoryBuilder的代码截图 SqlSessionFactory对象的创建需要内部配置类Configuration而调用方可能提供多种不同的源数据及配置。这其中的转换、验证逻辑均有Builder类来负责处理。
建造者模式优点
将对象创建过程与表示解耦满足单一职责原则由于相互独立对象的创建方式十分容易扩展
建造者模式缺点
建造者模式几乎没有缺点。最好用于创建复杂对象简单对象使用该模式会增加代码复杂度。
