建造者模式android,Android设计模式(二) 建造者模式

建造者模式解决的就是将一个复杂对象的构建与它的表示分离，从而使对象的构建过程能有不同的表示。什么意思？

fun main(args: Array) {

MacBook(15,8,16,512,true,"test","")

}

class MacBook(private var screenSize:Int,

private var cpuCore:Int,

private var ramCapacity:Int,

private var diskCapacity:Int,

private var appleCare:Boolean,

private var engraveWords:String,

private var protectingShell:String)

面对这种过长的参数构造函数，我们需要通过建造者模式来改造。

不管是之前提到的工厂模式还是单例，都没解决扩展大量可选参数的问题，例如上述我们在购买MacBook的时候都会进行可选产品定制，例如屏幕尺寸，处理器种类 ，内存大小，硬盘大小 ，Applecare，铭刻内容，配件...等等等

在业务中我们也经常使用重叠构造器(telescoping constructor)，先提供一个只有必要参数的构造函数，在提供其他不同参数组合的构造，但是如果参数过长是不利于维护的。所以我们用建造者模式改造：

fun main(args: Array) {

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(private var screenSize: Int? = null,

private var cpuCore: Int? = null,

private var ramCapacity: Int? = null,

private var diskCapacity: Int? = null,

private var appleCare: Boolean = false) {

fun setScreenSize(screenSize: Int?): Builder {

this.screenSize = screenSize

return this

}

fun setCpuCore(cpuCore: Int?): Builder {

this.cpuCore = cpuCore

return this

}

fun setRamCapacity(ramCapacity: Int?): Builder {

this.ramCapacity = ramCapacity

return this

}

fun setDiskCapacity(diskCapacity: Int?): Builder {

this.diskCapacity = diskCapacity

return this

}

fun setAppleCare(appleCare: Boolean): Builder {

this.appleCare = appleCare

return this

}

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) {

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) {

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

) {

// 路由跳转基础路径

fun getRouterBaseUrl(): String = "$departments/$category"

// 允许传递给WebView进程的URL

fun getWebViewEntryUrl(): 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"