定义
建造者模式的定义是：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。也就是说将构建过程和部件的表示隔离开，用户可以在不知道内部构建细节的情况下，对对象的构造流程进行相应的控制，比如在Android中典型的Builder模式就是AlerDialog.Builder类。
场景
相同方法，不同的执行顺序，产生不同的事件结果
多个部件可以装配到一个对象，但是产生的运行结果又不相同时
产品类复杂，或者，产品类调用顺序不同产生不同作用
当初始化一个对象很复杂，如参数多，且很多参数有默认值
UML结构图
产品类：一般是一个较为复杂的对象，也就是说创建对象的过程比较复杂，一般会有比较多的代码量。在本类图中，产品类是一个具体的类，而非抽象类。实际编程中，产品类可以是由一个抽象类与它的不同实现组成，也可以是由多个抽象类与他们的实现组成。
抽象建造者：引入抽象建造者的目的，是为了将建造的具体过程交与它的子类来实现。这样更容易扩展。一般至少会有两个抽象方法，一个用来建造产品，一个是用来返回产品。
建造者：实现抽象类的所有未实现的方法，具体来说一般是两项任务：组建产品；返回组建好的产品。
导演类：负责调用适当的建造者来组建产品，导演类一般不与产品类发生依赖关系，与导演类直接交互的是建造者类。一般来说，导演类被用来封装程序中易变的部分。
实际开发过程，Director角色经常会被忽略，直接使用Builder进行对象的组装， Builder通常为链式调用，结构更简单，对产品有更精细的控制
优点
良好的封装性，客户端不必关心产品内部组成细节
建造者独立，易扩展
缺点
产生多余的Builder对象以及Direactor对象，消耗内存
JAVA版的经典用例
public class Computer {
private String cpu;
private String ram;
private String mainboard;
private Computer(Builder builder) {
setCpu(builder.cpu);
setRam(builder.ram);
setMainboard(builder.mainboard);
}
public String getCpu() {
return cpu;
}
public void setCpu(String cpu) {
this.cpu = cpu;
}
public String getRam() {
return ram;
}
public void setRam(String ram) {
this.ram = ram;
}
public String getMainboard() {
return mainboard;
}
public void setMainboard(String mainboard) {
this.mainboard = mainboard;
}
@Override
public String toString() {
return (cpu!=null?("cpu:" + cpu):"") + (ram!=null?(" ,ram" + ram):"") + (mainboard!=null?(" ,mainboard" + mainboard):"");
}
static class Builder {
private String cpu;
private String ram;
private String mainboard;
public Builder cpu(String val) {
cpu = val;
return this;
}
public Builder ram(String val) {
ram = val;
return this;
}
public Builder mainboard(String val) {
mainboard = val;
return this;
}
public Computer build() {
return new Computer(this);
}
}
}Kotlin版用例
fun main(args: Array<String>) {
MacBook(15,8,16,512,true,"test","")
}
class MacBook(privatevar screenSize:Int,
privatevar cpuCore:Int,
privatevar ramCapacity:Int,
privatevar diskCapacity:Int,
privatevar appleCare:Boolean,
privatevar engraveWords:String,
privatevar protectingShell:String)
面对这种过长的参数构造函数，我们需要通过建造者模式来改造。
不管是之前提到的工厂模式还是单例，都没解决扩展大量可选参数的问题，例如上述我们在购买MacBook的时候都会进行可选产品定制，例如屏幕尺寸，处理器种类 ，内存大小，硬盘大小 ，Applecare，铭刻内容，配件...等等等
在业务中我们也经常使用重叠构造器(telescoping constructor)，先提供一个只有必要参数的构造函数，在提供其他不同参数组合的构造，但是如果参数过长是不利于维护的。所以我们用建造者模式改造：
fun main(args: Array<String>) {
MacBook.Builder()
.setScreenSize(15)
.setCpuCore(8)
.setRamCapacity(16)
.setDiskCapacity(512)
.setAppleCare(true)
.build()
}
class MacBook private constructor(var screenSize: Int,
var cpuCore: Int,
var ramCapacity: Int,
var diskCapacity: Int,
var appleCare: Boolean) {
class Builder(privatevar screenSize: Int? = null,
privatevar cpuCore: Int? = null,
privatevar ramCapacity: Int? = null,
privatevar diskCapacity: Int? = null,
privatevar appleCare: Boolean = false) {
fun setScreenSize(screenSize: Int?): Builder {
this.screenSize = screenSize
returnthis
}
fun setCpuCore(cpuCore: Int?): Builder {
this.cpuCore = cpuCore
returnthis
}
fun setRamCapacity(ramCapacity: Int?): Builder {
this.ramCapacity = ramCapacity
returnthis
}
fun setDiskCapacity(diskCapacity: Int?): Builder {
this.diskCapacity = diskCapacity
returnthis
}
fun setAppleCare(appleCare: Boolean): Builder {
this.appleCare = appleCare
returnthis
}
fun build(): MacBook {
return MacBook(screenSize!!, cpuCore!!, ramCapacity!!, diskCapacity!!, appleCare)
}
}
}步骤：
定义嵌套类Builder负责创建MacBook对象
私有化类MacBook的构造函数，确保无法直接通过MacBook声明实例
通过在Builder类中定义的可选属性来定制对象创建的内容
调用build()方法返回一个MacBook实例
这样比直接在构造函数中配置参数优雅了不少，创建实例时，只需要在对set方法进行赋值即可。
不足：
业务需求参数非常多时，代码依旧会显得比较长
build()方法经常会忘记调用
创建实例时必须先创建其构造器。
这是Java中典型的建造者模式，但在kotlin中我们其实可以尽量避免使用它，因为建造者模式本质上也是模拟了具名的可选参数 ，例如Flutter中的Dart使用 { }来包裹具名参数传递的时候，和参数顺序无关,当然kotlin也支持这种特性
void printTest(String name1, {String name2, String name3}) { }
复制代码具名可选参数
kotlin函数与构造器都支持具名可选参数,我们直接利用data class声明一个数据类 :
fun main(args: Array<String>) {
MacBook(screenSize = 15)
MacBook(appleCare = true ,screenSize = 15,cpuCore = 8)
}
data class MacBook(val screenSize: Int? = null,
val cpuCore: Int? = null,
val ramCapacity: Int? = null,
val diskCapacity: Int? = null,
val appleCare: Boolean? = null)这样我们声明对象时，每个参数名都是显式的，不用按照顺序定义参数内容，并且参数都由val声明更加安全
利用requair进行参数行为约束
为了让业务更加安全，我们经常会利用建造者模式中的属性进行业务行为约束
fun main(args: Array<String>) {
MacBook(cpuCore = 38)
}
class MacBook(val screenSize: Int? = null,
val cpuCore: Int? = null,
val ramCapacity: Int? = null,
val diskCapacity: Int? = null,
val appleCare: Boolean? = null) {
init {
require(cpuCore!! <= 32) {
"CPU核心数超过定制需求"
}
}
}这样当我们传入的参数定义符合requair中的约束，就会抛出异常：
Exception in thread "main" java.lang.IllegalArgumentException: CPU核心数超过定制需求当然这为了说明requair示例，具体这种业务还是需要数据配置例如枚举，自定义注解等进行详细约束的
数据模型独立
这里多说一句，上述requair没有使用data class，Kotlin中带有数据类的模型已经比Java同类的模型更精简和简洁。用一个data关键字抽象了所有参数的getters, setters、toString()和copy()方法，使我们的数据类能够反映出他们唯一需要关注的事情—数据模型独立。
所以我们在业务开发时可以借助Kotlin的扩展将业务或转换逻辑与数据模型分离，例如在我们在企业级IM应用中需要对用户页面或者访问内容进行动态分发
data class RongCloudCast(
val uuid: String,
val departments: String,
val category: String,
val website: String,
val version: String,
val hashCode: String
) {
// 路由跳转基础路径fungetRouterBaseUrl(): String = "$departments/$category"// 允许传递给WebView进程的URLfungetWebViewEntryUrl(): String = "https://$website/$version/$hashCode"
}相较于这种还是由扩展功能完成拼接逻辑
data class RongCloudCast(
val uuid: String,
val departments: String,
val category: String,
val website: String,
val version: String,
val hashCode: String
)
fun RongCloudCast.getRouterBaseUrl(): String = "$departments/$category"
fun RongCloudCast.getWebViewEntryUrl(): String = "https://$website/$version/$hashCode"
扫一扫
444
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
