(译)Effective Kotlin系列之遇到多个构造器参数要考虑使用Builder(二)

偏执的太偏执、 2022-05-15 08:48 203阅读 0赞

**翻译说明:**

**原标题: Effective Java in Kotlin, item 2: Consider a builder when faced with many constructor parameters**

**原文地址: [https://blog.kotlin-academy.com/effective-java-in-kotlin-item-2-consider-a-builder-when-faced-with-many-constructor-parameters-1927e69608e1][https_blog.kotlin-academy.com_effective-java-in-kotlin-item-2-consider-a-builder-when-faced-with-many-constructor-parameters-1927e69608e1]**

**原文作者: [Marcin Moskala][]**

这篇文章对Java程序员将会有很大的影响。当我们在处理各种各样的对象创建的操作是，这是一个很常见的场景。Effective Java中提出的很好的论据建议开发人员使用Builder构建器而不是伸缩构造函数模式。虽然Kotlin改变了很多 - 它给了我们更好的可能性。我们很快就会看到它

这是Effective Java edition 2的第二条规则：

*`面对许多构造函数时使用BUILDERS`*

让我们来探索吧。

## 内容前情回顾 ##

在Java中，通常方式是使用可选的构造函数参数的可伸缩构造器模式去定义一个对象。当我们使用可伸缩构造器模式时，可以为每个使用的集合或参数定义一个单独的构造器。以下是Kotlin的一个例子：

class Dialog constructor(
            val title: String,
            val text: String?,
            val onAccept: (() -> Unit)?
    ) {
        
        constructor(title: String, text: String)
            : this(title, text, null)
        constructor(title: String)
            : this(title, "")
    }
    // Usage
    val dialog1 = Dialog("Some title", "Great dialog", {
         toast("I was clicked") })
    val dialog2 = Dialog("Another dialog","I have no buttons")
    val dialog3 = Dialog("Dialog with just a title")

在Android中非常常见的例子就是我们[如何实现一个自定义View][View]。  
尽管这种模式在JVM世界中很流行，但是Effective Java认为对于更大或更复杂的对象，我们应该使用Builder模式。Builder模式首先以可读和紧凑的方式获取参数列表，然后验证并实例化对象。这是一个例子：

class Dialog private constructor(
            val title: String,
            val text: String?,
            val onAccept: (() -> Unit)?
    ) {
        
        class Builder(val title: String) {
        
            var text: String? = null
            var onAccept: (() -> Unit)? = null
            fun setText(text: String?): Builder {
        
                this.text = text
                return this
            }
            fun setOnAccept(onAccept: (() -> Unit)?): Builder {
        
                this.onAccept = onAccept
                return this
            }
            fun build() = Dialog(title, text, onAccept)
        }
    }
    // Usage
    val dialog1 = Dialog.Builder("Some title")
            .setText("Great dialog")
            .setOnAccept {
         toast("I was clicked") }
            .build()
    val dialog2 = Dialog.Builder("Another dialog")
            .setText("I have no buttons")
            .build()
    val dialog3 = Dialog.Builder("Dialog with just a title").build()

在可伸缩的构造器模式中，声明和用法都显得比较强大，但是builder模式有着更为重要的优点:

*  参数是显式的，因此我们在设置它时会看到每个参数的名称。
 *  我们可以按任何顺序设置参数。
 *  它更容易修改，因为当我们需要在可伸缩的构造器模式中更改某些参数时，我们需要在使用它的所有构造函数中更改它。
 *  具有填充值的Builder构建器可以像工厂一样使用。

当我们需要设置可选参数时，这个特性使构建器模式对大多数类更加明确，有弹性并且更好。

## 命名可选参数 ##

本章最受欢迎的部分，来自Effective Java的第二版，如下：

*`Builder模式模拟Ada和Python语言中的命名可选参数。`*

很棒的是，在Kotlin中，我们不需要模拟命名的可选参数，因为我们可以直接使用它们。在大多数情况下，可选参数比Builder构建器要更好。只需比较上面的构建器模式和下面命名的可选参数即可，就会发现声明和使用都更清晰，更短，更具表现力:

class Dialog(
            val title: String,
            val text: String? = null,
            val onAccept: (() -> Unit)? = null
    )
    // Usage
    val dialog1 = Dialog(
            title = "Some title",
            text = "Great dialog",
            onAccept = {
         toast("I was clicked") }
    )
    val dialog2 = Dialog(
            title = "Another dialog",
            text = "I have no buttons"
    )
    val dialog3 = Dialog(title = "Dialog with just a title")

具有命名可选参数的构造函数具有Builder构建器模式的大部分优点

*  参数是显式的，因此我们在设置时设置每个参数的名称。
 *  我们可以按任何顺序设置参数。
 *  它更容易修改（甚至比Builder构建器模式更容易）

在这个简单的示例中，具有命名可选参数的构造函数看起来更好,但是，如果我们需要针对不同参数的不同创建变体呢？假设我们为不同的参数集创建不同类型的对话框。我们可以在Builder构建器中轻松地解决该问题：

interface Dialog {
        
        fun show()
        class Builder(val title: String) {
        
            var text: String? = null
            var onAccept: (() -> Unit)? = null
            fun setText(text: String?): Builder {
        
                this.text = text
                return this
            }
            fun setOnAccept(onAccept: (() -> Unit)?): Builder {
        
                this.onAccept = onAccept
                return this
            }
            fun build(): Dialog = when {
        
                text != null && onAccept != null ->
                    TitleTextAcceptationDialog(title, text!!, onAccept!!)
                text != null ->
                    TitleTextDialog(title, text!!)
                onAccept != null ->
                    TitleAcceptationDialog(title, onAccept!!)
                else -> TitleDialog(title)
            }
        }
    }
    // Usage
    val dialog1 = Dialog.Builder("Some title")
            .setText("Great dialog")
            .setOnAccept {
         toast("I was clicked") }
            .build()
    val dialog2 = Dialog.Builder("Another dialog")
            .setText("I have no buttons")
            .build()
    val dialog3 = Dialog.Builder("Dialog with just a title").build()

那我们可以使用命名的可选参数来解决该类问题吗？是的，我们可以使用不同的构造函数或使用工厂方法来实现相同的功能！以下是针对上述问题示例的解决方案：

interface Dialog {
        
        fun show()
    }
    fun makeDialog(
        title: String, 
        text: String? = null, 
        onAccept: (() -> Unit)?
    ): Dialog = when {
        
        text != null && onAccept != null -> 
            TitleTextAcceptationDialog(title, text, onAccept)
        text != null -> 
            TitleTextDialog(title, text)
        onAccept != null -> 
            TitleAcceptationDialog(title, onAccept)
        else -> 
            TitleDialog(title)
    }
    // Usage
    val dialog1 = makeDialog(
            title = "Some title",
            text = "Great dialog",
            onAccept = {
         toast("I was clicked") }
    )
    val dialog2 = makeDialog(
            title = "Another dialog",
            text = "I have no buttons"
    )
    val dialog3 = makeDialog(title = "Dialog with just a title")

这是我们的另一个例子，我们再次看到命名参数优于builder模式的地方：

*  它更短 - 构造函数或工厂方法比构建器模式更容易实现。我们不需要在调用地方指定每个可选参数的函数名称4次（作为属性，方法，参数和构造函数的名称）。类型不需要声明3次（在参数，属性和构造函数中）。这很重要，因为当我们想要更改某些参数名称时，我们只更改工厂方法中的单个声明即可，而不要去修改认为相同的4个方法名。
 *  它更清晰 - 当你想要查看对象构造的实现方式时，您需要的只是一个方法而不是遍布整个构建器类。对象之间如何引用？他们之间如何通信？当我们拥有比较复杂的Builder构建器时，这些问题一时都很难去回答。另一方面，类创建通常在工厂方法中是很明确的。
 *  没有并发问题 - 这不是个很常见的问题，但函数参数在Kotlin中总是不可变的，而大多数建设者的属性是可变的。因此，为Builder构建器实现线程安全构建函数显得更加困难。

Builder构建器模式的一个优点在于具有填充参数特性可用作工厂模式。虽然这种情况很少见，但这种优势微乎其微。

Builder构建器模式的另一个讨论点是我们可以部分填充构建器并进一步传递它。这样我们就可以定义创建部分填充构建器的方法，并且可以修改它们（比如我们的应用程序的默认对话框)。为了有类似的构造函数或工厂方法的可能性，我们需要自动的柯里化（这在Kotlin中是可能的，但不是没有名称和默认参数丢失）。虽然这种对象创建方式不是非常常见，但通常也不是优选的。如果我们要为应用程序定义默认对话框，可以使用函数来创建它并将所有自定义元素作为可选参数传递。这种方法可以更好地控制对话框Dialog的创建。

一般规则是，在大多数情况下，命名可选参数应优先于构建器模式。尽管这不是Kotlin给我们的Builder建造者模式的唯一新选择。另一个非常受欢迎的是用于对象构建的DSL。我们来描述一下。

## 用于构建对象的DSL ##

假设我们需要设置具有多个处理程序的监听器。类似于Java的经典方法是使用对象表达式：

taskNameView.addTextChangedListener(object : TextWatcher {
        
        override fun afterTextChanged(s: Editable?) {
        
            // ...
        }
        override fun beforeTextChanged(s: CharSequence?, start: Int, count: Int, after: Int) {
        
            // ...
        }
        override fun onTextChanged(s: CharSequence?, start: Int, before: Int, count: Int) {
        
            // no-op
        }
    })

这种方法不是很方便，可以使用命名的可选参数轻松替换为更简洁的工厂方法：

fun makeTextWatcher(
            afterTextChanged: ((s: Editable?) -> Unit)? = null,
            beforeTextChanged: ((s: CharSequence?, start: Int, count: Int, after: Int) -> Unit)? = null,
            onTextChanged: ((s: CharSequence?, start: Int, before: Int, count: Int) -> Unit)? = null
    ) = object : TextWatcher {
        
        override fun afterTextChanged(s: Editable?) {
        
            afterTextChanged?.invoke(s)
        }
        override fun beforeTextChanged(s: CharSequence?, start: Int, count: Int, after: Int) {
        
            beforeTextChanged?.invoke(s, start, count, after)
        }
        override fun onTextChanged(s: CharSequence?, start: Int, before: Int, count: Int) {
        
            onTextChanged?.invoke(s, start, before, count)
        }
    }
    // Usage
    taskNameView.addTextChangedListener(makeTextWatcher(
            afterTextChanged = {
         s ->
                // ..
            },
            beforeTextChanged = {
         s, start, count, after ->
                // ...
            }
    ))

请注意，我们可以轻松地把进一步改造成TextView的扩展函数:

taskNameView.addTextChangedListener(
        afterTextChanged = {
         s ->
           // ..
        },
        beforeTextChanged = {
         s, start, count, after ->
           // ...
        }
    )

这是DSL的一个简单示例。支持这种表示法的函数可以在类似[Anko][]或[Android-ktx][]这样的流行Kotlin库中找到。例如，这是我们如何在Anko中定义和显示warning对话框：

alert("Hi, I'm Roy", "Have you tried turning it off and on again?"){
        
        yesButton {
         toast("Oh…") }
        noButton {
        }
    }.show()

问题在于这种表示方法需要写很多支持它们的声明，例如这是我们如何定义上面的TextView的addOnTextChangedListener扩展方法:

fun TextView.addOnTextChangedListener(
        config: TextWatcherConfiguration.() -> Unit
    ) {
        
        val listener = TextWatcherConfiguration().apply {
         config() }
        addTextChangedListener(listener)
    }
    class TextWatcherConfiguration : TextWatcher {
        
        private var beforeTextChangedCallback: (BeforeTextChangedFunction)? = null
        private var onTextChangedCallback: (OnTextChangedFunction)? = null
        private var afterTextChangedCallback: (AfterTextChangedFunction)? = null
        fun beforeTextChanged(callback: BeforeTextChangedFunction) {
        
           beforeTextChangedCallback = callback
        }
        fun onTextChanged(callback: OnTextChangedFunction) {
        
            onTextChangedCallback = callback
        }
        fun afterTextChanged(callback: AfterTextChangedFunction) {
        
            afterTextChangedCallback = callback
        }
        override fun beforeTextChanged(
            s: CharSequence, 
            start: Int, 
            count: Int, 
            after: Int
        ) {
        
            beforeTextChangedCallback?.invoke(s.toString(), start, count, after)
        }
        override fun onTextChanged(
             s: CharSequence, 
             start: Int, 
             before: Int, 
             count: Int
        ) {
        
            onTextChangedCallback?.invoke(s.toString(), start, before, count)
        }
        override fun afterTextChanged(s: Editable) {
        
            afterTextChangedCallback?.invoke(s)
        }
    }
    private typealias BeforeTextChangedFunction = 
        (text: String, start: Int, count: Int, after: Int) -> Unit
    private typealias OnTextChangedFunction = 
        (text: String, start: Int, before: Int, count: Int) -> Unit
    private typealias AfterTextChangedFunction = 
        (s: Editable) -> Unit

对单个甚至两个用法进行此类声明是不合理的。另一方面，当我们开发一个库时，这不是问题。这就是为什么在大多数情况下我们使用库中定义的DSL的原因。当我们定义它们时，它们非常强大。请注意，在DSL内部，包括使用控制循环语句结构（`if` `for`，等等），定义变量等。这是一个为[Kot.Academy官网][Kot.Academy]生成的HTML使用DSL的例子。

private fun RDOMBuilder<DIV>.authorDiv(
        author: String?, 
        authorUrl: String?
    ) {
        
        author ?: return
        div(classes = "main-text multiline space-top") {
        
            +"Author: "
            if (authorUrl.isNullOrBlank()) {
        
                +author
            } else {
        
                a(href = authorUrl) {
         +author }
            }
        }
    }

除了声明之外，我们也指定了如何定义这个元素的逻辑。这样的DSL通常比具有命名可选参数的构造函数或工厂方法强大得多。当然它也更复杂，更难定义。

## 用于已经有Builder构建者的简单DSL使用 ##

在一些Android项目中可以观察到有趣的解决方案，其中开发人员实现了使用切除构建器的简化DSL。

假设我们使用来自库（或框架）的对话框Dialog，它提供构建器作为创建方法（假设它是用Java实现的）：

val dialog1 = Dialog.Builder("Some title")
            .setText("Great dialog")
            .setOnAccept {
         toast("I was clicked") }
            .build()

这就是如何实现和使用非常简单的DSL构建器：

fun Dialog(title: String, init: Dialog.Builder.()->Unit) = 
        Dialog.Builder(title).apply(init).build()
    // Usage
    val dialog1 = Dialog("Some title") {
        
         text = "Great dialog"
         setOnAccept {
         toast("I was clicked") }
    }

(只有在Java中定义了此方法时，我们才能将`text`设置为属性)  
这样我们就拥有了DSL的最大优点和非常简单的声明。这也表明了DSL和Builder构建器模式的共同点。他们有类似的理念，但DSL更像是下一代的建造者模式。

## 总结 ##

Effective Java的参数在Kotlin中仍然有效，而构建器模式比之前的Java替代方案更合理。尽管 Kotlin介绍了按名称指定参数并提供默认参数。多亏了这一点，我们可以更好地替代构建器模式。Kotlin还提供了允许DSL使用的功能。定义良好的DSL甚至是更好的替代方案，因为它提供了更大的灵活性并允许在对象定义实现逻辑。

去判定对象创建到底有多复杂不是一个简单的问题，而且往往需要一定的经验。Kotlin给我们带来非常重要的可能性，此外它们对Kotlin的发展也产生了积极的影响。

## 译者有话说 ##

首先，回答下为什么要翻译这篇文章，这篇文章是Effective Kotlin系列的第二篇，这篇讲的是我们熟悉的Builder建造者模式，当我们遇到构造器中有很多参数的时，我都会考虑使用Builder模式来替代它。当然这只是Java中常见操作，但是Kotlin是不是得按部就班照着Java来呢？显然不是，Kotlin中有着更为优雅和强大的实现方式构造器+默认值参数。如果不了解本篇文章初学者，估计就会拿着Kotlin语言生搬硬套成Java的Builder实现方式，却不知Kotlin中有更为优雅的实现方案。

其实，本篇文章继续体现Effective Kotlin一个宗旨: 通过对比Effective Java高效编码准则，在Kotlin中去寻找更为优雅实现方式和替代解决方案，而不是带着Java思维写着Kotlin代码来翻译实现。从而进一步体验Kotlin与Java不同以及各自优缺点。

![1635c3fb0ba21ec1_w_430_h_430_f_jpeg_s_39536][]

**欢迎关注Kotlin开发者联盟，这里有最新Kotlin技术文章，每周会不定期翻译一篇Kotlin国外技术文章。如果你也喜欢Kotlin，欢迎加入我们~~~**

### Kotlin系列文章，欢迎查看: ###

> Kotlin邂逅设计模式系列:

*  **[当Kotlin完美邂逅设计模式之单例模式(一)][Kotlin]**

> 数据结构与算法系列:

*  **[每周一算法之二分查找(Kotlin描述)][Kotlin 1]**

> 翻译系列：

*  **[\[译\] Kotlin中关于Companion Object的那些事][Kotlin_Companion Object]**
 *  **[\[译\]记一次Kotlin官方文档翻译的PR(内联类)][Kotlin_PR]**
 *  **[\[译\]Kotlin中内联类的自动装箱和高性能探索(二)][Kotlin 2]**
 *  **[\[译\]Kotlin中内联类(inline class)完全解析(一)][Kotlin_inline class]**
 *  **[\[译\]Kotlin的独门秘籍Reified实化类型参数(上篇)][Kotlin_Reified]**
 *  **[\[译\]Kotlin泛型中何时该用类型形参约束?][Kotlin 3]**
 *  **[\[译\] 一个简单方式教你记住Kotlin的形参和实参][_Kotlin]**
 *  **[\[译\]Kotlin中是应该定义函数还是定义属性?][Kotlin 4]**
 *  **[\[译\]如何在你的Kotlin代码中移除所有的!!(非空断言)][Kotlin 5]**
 *  **[\[译\]掌握Kotlin中的标准库函数: run、with、let、also和apply][Kotlin_ run_with_let_also_apply]**
 *  **[\[译\]有关Kotlin类型别名(typealias)你需要知道的一切][Kotlin_typealias]**
 *  **[\[译\]Kotlin中是应该使用序列(Sequences)还是集合(Lists)?][Kotlin_Sequences_Lists]**
 *  **[\[译\]Kotlin中的龟(List)兔(Sequence)赛跑][Kotlin_List_Sequence]**

> 原创系列：

*  **[教你如何完全解析Kotlin中的类型系统][Kotlin 6]**
 *  **[如何让你的回调更具Kotlin风味][Kotlin 7]**
 *  **[Jetbrains开发者日见闻(三)之Kotlin1.3新特性(inline class篇)][Jetbrains_Kotlin1.3_inline class]**
 *  **[JetBrains开发者日见闻(二)之Kotlin1.3的新特性(Contract契约与协程篇)][JetBrains_Kotlin1.3_Contract]**
 *  **[JetBrains开发者日见闻(一)之Kotlin/Native 尝鲜篇][JetBrains_Kotlin_Native]**
 *  **[教你如何攻克Kotlin中泛型型变的难点(实践篇)][Kotlin 8]**
 *  **[教你如何攻克Kotlin中泛型型变的难点(下篇)][Kotlin 9]**
 *  **[教你如何攻克Kotlin中泛型型变的难点(上篇)][Kotlin 10]**
 *  **[Kotlin的独门秘籍Reified实化类型参数(下篇)][Kotlin_Reified 1]**
 *  **[有关Kotlin属性代理你需要知道的一切][Kotlin 11]**
 *  **[浅谈Kotlin中的Sequences源码解析][Kotlin_Sequences]**
 *  **[浅谈Kotlin中集合和函数式API完全解析-上篇][Kotlin_API_-]**
 *  **[浅谈Kotlin语法篇之lambda编译成字节码过程完全解析][Kotlin_lambda]**
 *  **[浅谈Kotlin语法篇之Lambda表达式完全解析][Kotlin_Lambda]**
 *  **[浅谈Kotlin语法篇之扩展函数][Kotlin 12]**
 *  **[浅谈Kotlin语法篇之顶层函数、中缀调用、解构声明][Kotlin 13]**
 *  **[浅谈Kotlin语法篇之如何让函数更好地调用][Kotlin 14]**
 *  **[浅谈Kotlin语法篇之变量和常量][Kotlin 15]**
 *  **[浅谈Kotlin语法篇之基础语法][Kotlin 16]**

> Effective Kotlin翻译系列

*  **[\[译\]Effective Kotlin系列之考虑使用原始类型的数组优化性能(五)][Effective Kotlin]**
 *  **[\[译\]Effective Kotlin系列之使用Sequence来优化集合的操作(四)][Effective Kotlin_Sequence]**
 *  **[\[译\]Effective Kotlin系列之探索高阶函数中inline修饰符(三)][Effective Kotlin_inline]**
 *  **[\[译\]Effective Kotlin系列之遇到多个构造器参数要考虑使用构建器(二)][Effective Kotlin 1]**
 *  **[\[译\]Effective Kotlin系列之考虑使用静态工厂方法替代构造器(一)][Effective Kotlin 2]**

> 实战系列:

*  **[用Kotlin撸一个图片压缩插件ImageSlimming-导学篇(一)][Kotlin_ImageSlimming-]**
 *  **[用Kotlin撸一个图片压缩插件-插件基础篇(二)][Kotlin_-]**
 *  **[用Kotlin撸一个图片压缩插件-实战篇(三)][Kotlin_- 1]**
 *  **[浅谈Kotlin实战篇之自定义View图片圆角简单应用][Kotlin_View]**

[https_blog.kotlin-academy.com_effective-java-in-kotlin-item-2-consider-a-builder-when-faced-with-many-constructor-parameters-1927e69608e1]: https://blog.kotlin-academy.com/effective-java-in-kotlin-item-2-consider-a-builder-when-faced-with-many-constructor-parameters-1927e69608e1
[Marcin Moskala]: https://blog.kotlin-academy.com/@marcinmoskala?source=post_header_lockup
[View]: https://www.intertech.com/Blog/android-custom-view-tutorial-part-1-combining-existing-views/
[Anko]: https://github.com/Kotlin/anko
[Android-ktx]: https://github.com/android/android-ktx
[Kot.Academy]: https://github.com/MarcinMoskala/KotlinAcademyApp
[1635c3fb0ba21ec1_w_430_h_430_f_jpeg_s_39536]: https://user-gold-cdn.xitu.io/2018/5/14/1635c3fb0ba21ec1?w=430&h=430&f=jpeg&s=39536
[Kotlin]: https://blog.csdn.net/u013064109/article/details/89078666
[Kotlin 1]: https://blog.csdn.net/u013064109/article/details/89023937
[Kotlin_Companion Object]: https://blog.csdn.net/u013064109/article/details/89199478
[Kotlin_PR]: https://blog.csdn.net/u013064109/article/details/85180755
[Kotlin 2]: https://blog.csdn.net/u013064109/article/details/84899657
[Kotlin_inline class]: https://blog.csdn.net/u013064109/article/details/84866092
[Kotlin_Reified]: https://blog.csdn.net/u013064109/article/details/83388976
[Kotlin 3]: https://blog.csdn.net/u013064109/article/details/83120352
[_Kotlin]: https://blog.csdn.net/u013064109/article/details/83099581
[Kotlin 4]: https://blog.csdn.net/u013064109/article/details/80344848
[Kotlin 5]: https://blog.csdn.net/u013064109/article/details/80358822
[Kotlin_ run_with_let_also_apply]: https://blog.csdn.net/u013064109/article/details/80387322
[Kotlin_typealias]: https://blog.csdn.net/u013064109/article/details/80444565
[Kotlin_Sequences_Lists]: https://blog.csdn.net/u013064109/article/details/80562009
[Kotlin_List_Sequence]: https://blog.csdn.net/u013064109/article/details/80740230
[Kotlin 6]: https://blog.csdn.net/u013064109/article/details/88985474
[Kotlin 7]: https://blog.csdn.net/u013064109/article/details/86695094
[Jetbrains_Kotlin1.3_inline class]: https://blog.csdn.net/u013064109/article/details/84837918
[JetBrains_Kotlin1.3_Contract]: https://blog.csdn.net/u013064109/article/details/84782206
[JetBrains_Kotlin_Native]: https://blog.csdn.net/u013064109/article/details/84729814
[Kotlin 8]: https://blog.csdn.net/u013064109/article/details/84504847
[Kotlin 9]: https://blog.csdn.net/u013064109/article/details/84060626
[Kotlin 10]: https://blog.csdn.net/u013064109/article/details/83869716
[Kotlin_Reified 1]: https://blog.csdn.net/u013064109/article/details/83507076
[Kotlin 11]: https://blog.csdn.net/u013064109/article/details/82794410
[Kotlin_Sequences]: https://blog.csdn.net/u013064109/article/details/80588034
[Kotlin_API_-]: https://blog.csdn.net/u013064109/article/details/80275942
[Kotlin_lambda]: https://blog.csdn.net/u013064109/article/details/80139556
[Kotlin_Lambda]: https://blog.csdn.net/u013064109/article/details/80088158
[Kotlin 12]: https://blog.csdn.net/u013064109/article/details/79968846
[Kotlin 13]: https://blog.csdn.net/u013064109/article/details/79887528
[Kotlin 14]: https://blog.csdn.net/u013064109/article/details/79503709
[Kotlin 15]: https://blog.csdn.net/u013064109/article/details/79296502
[Kotlin 16]: https://blog.csdn.net/u013064109/article/details/77843579
[Effective Kotlin]: https://blog.csdn.net/u013064109/article/details/84996951
[Effective Kotlin_Sequence]: https://blog.csdn.net/u013064109/article/details/84981570
[Effective Kotlin_inline]: https://blog.csdn.net/u013064109/article/details/84948769
[Effective Kotlin 1]: https://blog.csdn.net/u013064109/article/details/82121020
[Effective Kotlin 2]: https://blog.csdn.net/u013064109/article/details/81916446
[Kotlin_ImageSlimming-]: https://blog.csdn.net/u013064109/article/details/80850992
[Kotlin_-]: https://blog.csdn.net/u013064109/article/details/80879296
[Kotlin_- 1]: https://blog.csdn.net/u013064109/article/details/81814643
[Kotlin_View]: https://blog.csdn.net/u013064109/article/details/80102036