什么是设计者模式
在开发软件时候针对常见问题的“通用”解决方法。可以理解为游戏中的攻略,即遇到同类问题时候如何走位,如何释放技能。
设计模式的作用
最直接的作用就是减少烂代码,让项目更好维护。如果没学过设计模式,可能随着产品的需求的不断增加,代码中充满大量的if else,导致只能继续在里面添加if else 来增加新的功能。但如果使用了设计模型的话,我们可以把每段逻辑单独封装和维护,增加协作开发的效率。很多知名的项目也用到了设计模式,比如spring和mybatis
建造者模式
概述
将一个复杂对象的构建与表示分离,使得同样的构建过程可以创建不同的表示。
这句话中,构建就代指主板、cpu、内存条、显卡、风扇等,表示就代指主机。使得同样的构建过程可以创建不同的表示就代指假设我内存条、cpu、主板都换了一个品牌,虽然组装方式不变,但最后组装出来的电脑却不是原来的电脑了。
分离的好处就是解耦合
- 分离了部件的构造(由Builder来负责)和装配(由Director负责)。从而可以构造出复杂的对象,这个模式适用于:某个对象的构造过程复杂的情况
- 由于实现了构造和装配的解耦,不同的构造器,系统的装配,也可以做出不同的对象;系统的构造器,不同的装配顺序也可以做出不同的对象。也就实现了构建算法、装配算法的解耦,实现了更好的复用。
- 建造者模式可以将部件和其他组装过程分开,一步一步创建一个复杂的对象,用户只需要指定复杂对象的类型就可以得到该对象,而无需知道其内部的具体构造细节。
结构
建造者(Builder)模式包含如下角色:
- 抽象建造者(Builder):这个接口规定要实现复杂对象的那些部分的创建,并不涉及具体的部件对象的创建。
- 具体建造者类(ConcerteBuilder):实现Builder接口,完成复杂产品的各个部件的具体创建方法,,在构造完成后,提供产品的实例。
- 产品类(Product):要创建的复杂对象
- 指挥者类(Director):调用具体建造者来创建复杂对象的各个部分,在指导者中不涉及具体的产品信息,只负责保证对象各部分完整创建或按某种顺序创建。
类图如下:
示例代码
- 抽象建造者(Builder):我的理解是那些说提需求的甲方。甲方说,我要造一辆自行车,这个自行车有框架和座包,你去给我组装一辆出来
public abstract class Builder {
// 声明Bike类型的变量,并进行赋值
protected Bike bike = new Bike();
public abstract void buildFrame();
public abstract void buildSeat();
//构建自行车的方法
public abstract Bike createBike();
}
- 具体建造者(ConcerteBuilder):一群苦逼的打工仔,这群打工仔各自身怀绝技,有的会做框架,有的会搞座包,但他们都是松散的,没有一个组织他们的头头,所以不能独立做出单车来
// 具体建造者1:摩拜单车
public class MobileBuilder extends Builder {
@Override
public void buildFrame() {
bike.setFrame("全铝框架");
}
@Override
public void buildSeat() {
bike.setSeat("真皮座包");
}
@Override
public Bike createBike() {
return bike;
}
}
//具体建造者2:ofo单车
public class OfoBuilder extends Builder {
@Override
public void buildFrame() {
bike.setFrame("钛合金框架");
}
@Override
public void buildSeat() {
bike.setSeat("鳄鱼皮座包");
}
@Override
public Bike createBike() {
return bike;
}
}
- 指挥者类(Director):这就类似于领导,他主要就是负责指挥这群苦逼的打工仔,让他们在相互配合下共同完成这一辆单车的创建
public class Director {
private Builder builder;
public Director(Builder builder){
this.builder = builder;
}
// 组装自行车的方法
public Bike construct(){
builder.buildFrame();
builder.buildSeat();
return builder.createBike();
}
}
注意:
上面示例是Builder模式的常规用法,指挥者类Director在建造者模式中具有很重要的作用,它用来知道具体构建者如何构建产品,控制调用先后次序,并向调用者放回完整的产品类,但是有些情况下需要简化系统结构,可以把指挥者类和抽象建造者进行结合
// 抽象builder类
public abstract class Builder {
// 声明Bike类型的变量,并进行赋值
protected Bike bike = new Bike();
public abstract void buildFrame();
public abstract void buildSeat();
//构建自行车的方法
public abstract Bike createBike();
public Bike construct(){
this.buildFrame();
this.BuildSeat();
return this.createBike();
}
}
说明:
这样做确实简化了系统结构,但同时也加重了抽象建造者的职责,也不是太符合单一职责原则,如果construct()过于复杂,建议还是封装到Director中。
优缺点
优点:
- 建造者模式的封装性很好,使用建造者模式可以有效的封装变化,在使用建造者模式的场景中,一般 产品类和建造者类是比较稳定的,因此,将主要的业务逻辑封装在指挥者类中对整体而言可以取得比较好的稳定性
- 在建造者模式中,客户端不必知道产品内部组成的细节,将产品本身与产品的创建过程解耦,使得相同的创建过程可以创建不同的产品对象。
- 可以更加精细的控制产品的创建过程,将复杂产品的创建步骤分解在不同宁大方法中,使得创建过程更加清晰,也更方便使用程序来控制创建过程。
- 建造者模式很容易进行扩展,如果有新的需求,通过实现一个新的建造者类就可以完成,基本上不用修改之前已经测试通过的代码,因此也就不会对原有功能引入风险,符合开闭原则
缺点:
建造者模式所创建的产品一般具有较多的共同特点,其组成部分相似,如果产品之间的差异性很大,则不适合使用建造者模式,因此其使用范围受到一定的限制。
使用场景
建造者模式创建的是复杂对象,其产品的各个部分经常面临着剧烈的变化,但将他们组合在一起的算法却相对稳定,所以它通常在以下场合使用。
- 创建的对象较复杂,由多个部件构成,各部件面临着复杂的变化,但构件间的构造顺序却是稳定的
- 创建复杂对象的算法独立于该对象的组成部分以及它们的装配方式,即产品的构建过程和最终的表示是独立的
创建者模式对比
工厂方法模式vs建造者模式
工厂方法模式注重的是整体对象的创建方式;而建造者模式注重的是部件构造的过程,意在通过一步一步的精确构造创建出一个复杂的对象。
例如:如果要制造一个超人,使用工厂方法模式,直接产生出来的就是一个力大无穷的超人;而如果使用创建者模式,则需要组装超人的手 、脚、头 、躯干等部分。
服务器托管,北京服务器托管,服务器租用 http://www.fwqtg.net
机房租用,北京机房租用,IDC机房托管, http://www.fwqtg.net
相关推荐: httprunner 4.x学习 – 13. upload 文件上传
前言 requests 库里面上传文件会用到 requests_toolbelt, 可以很方便的解决 multipart/form-data 类型的文件上传相关接口。 HttpRunner4.x 集成了 requests_toolbelt,可以使用内置 upl…