Kotlin 的扩展函数其实只是多态的表现形式之一。
子类型多态
继承父类后，用子类实例使用父类的方法，例如：
然后我们就可以使用父类DatabaseHelper的所有方法。这种用子类型替换超类型实例的行为，就是我们通常说的子类型多态。
class CustomerDatabaseHelper(context: Context) : SQLiteOpenHelper(context) {
override fun onUpgrade(p0: SQLiteDatabase?, p1: Int, p2: Int) {}
override fun onCreate(db: SQLiteDatabase) {
val sql = "CREATE TABLE if not exists $tableName ( id integer PRIMARY KEY);"
db.execSQL(sql)
}
}
然后我们就可以使用父类DatabaseHelper的所有方法。这种用子类型替换超类型实例的行为，就是我们通常说的子类型多态。
参数多态
在完成数据库的创建之后，现在我们要把客户（Customer）存入客户端数据库中。可能会写这样一个方法：
fun persist(customer: Customer) {
db.save(customer.uniqueKey, customer)
}
随着需求的变动，我们可能还会持久化多种类型的数据。如果每种类型都写一个presist方法，多少有些烦琐，通常我们会抽象一个方法来处理不同类型的持久化。因为我们采用键值对的方式存储，所以需要获取不同类型对应的uniqueKey：
interface IKey {
val uniqueKey: String
}
class ClassA(override val uniqueKey: String) : IKey
class ClassB(override val uniqueKey: String) : IKey
这样，class A、B 都已经具备uniqueKey。我们可以将persist进行如下改写：
fun <T : IKey> persist(t: T) {
db.save(t.uniqueKey, t)
}
以上的多态形式我们可以称之为参数多态，其实最常见的参数多态的形式就是泛型。
假使当对应的业务类ClassA、ClassB是第三方引入的，且不可被修改时，如果我们要想给它们扩展一些方法，比如将对象转化为Json，利用之前介绍的多态技术就会显得比较麻烦。
利用Kotlin支持的扩展语法，就能给 ClassA、ClassB添加方法或属性，从而换一种思路来解决上面的问题。
fun ClassA.toJson(): String = {
......
}
需要注意的是，扩展属性和方法的实现运行在ClassA实例，它们的定义操作并不会修改ClassA类本身。这样就为我们带来了一个很大的好处，即被扩展的第三方类免于被污染，从而避免了一些因父类修改而可能导致子类出错的问题发生。
当然，在 Java 中我们可以依靠其他的办法比如设计模式来解决，但相较而言依靠扩展的方案显得更加方便且合理，这其实也是另一种被称为特设多态的技术。
可能你对特设多态这个概念并不是很了解，我们来举一个具体的例子。当你想定义一个通用的sum方法时，也许会在Kotlin中这么写：
fun <T> sum(x : T, y : T) : T = x + y
但编译器会报错，因为某些类型T的实例不一定支持加法操作，而且如果针对一些自定义类，我们更希望能够实现各自定制化的“加法语义上的操作”。
如果把参数多态做的事情打个比方：它提供了一个工具，只要一个东西能“切”，就用这个工具来切割它。然而，现实中不是所有的东西都能被切，而且材料也不一定相同。更加合理的方案是，你可以根据不同的原材料来选择不同的工具来切它。
再换种思路，我们可以定义一个通用的Summable接口，然后让需要支持加法操作的类来实现它的plusThat方法。就像这样：
interface Sumable<T> {
fun plusThat(that: T): T
}
data class Len(val v: Int) : Sumable<Len> {
override fun plusThat(that: Len) = Len(this.v + that.v)
}
可以发现，当我们在自定义一个支持plusThat方法的数据结构如Len时，这种做法并没有什么问题。然而，如果我们要针对不可修改的第三方类扩展加法操作时，这种通过子类型多态的技术手段也会遇到问题。
于是，你又想到了 Kotlin 的扩展，也就是叫作“ 特设多态” 技术。特设多态可以理解为：一个多态函数是有多个不同的实现，依赖于其实参而调用相应版本的函数。
针对以上的例子，我们完全可以采用扩展的语法来解决问题。此外，Kotlin原生支持了一种语言特性来很好地解决问题，这就是运算符重载。借助这种语法，我们可以完美地实现需求。代码如下：
data class Area(val value: Double)
operator fun Area.plus(that: Area): Area {
return Area(this.value + that.value)
}
fun main() {
println(Area(1.0) + Area(2.0)) // 运行结果: Area(value=3.0)
}
operator关键字的作用是：将一个函数标记为重载一个操作符或者实现一个约定。
注意，这里的 plus 是 Kotlin 规定的函数名。除了重载加法，我们还可以通过重载减法（minus）、乘法（times）、除法（div）、取余（mod）（Kotlin 1.1 版本开始被rem替代）等函数来实现重载运算符。
此外，kotlin的一些基础语法也是利用运算符重载来实现的，如：
对开发者而言，在修改现有代码的时候，应当遵守设计模式中 OO 设计原则中的开闭原则，然而实际情况并不乐观，比如在进行 Android 开发的时候，为了实现某个需求，我们引入了一个第三方库。但某一天需求发生了变动，当前库无法满足，且库的作者暂时没有升级的计划。这时候也许你就会开始尝试对库源码进行修改。这就违背了开放封闭原则。随着需求的不断变更，问题可能就会如滚雪球般增长。
Java中一种惯用的应对方案是让一个子类继承第三方库的类，然后在其中添加新功能。然而，强行的继承可能违背“ 里氏替换原则” 。
Kotlin的扩展语言特性为我们提供了一种更合理的方案，通过扩展一个类的新功能而无须继承该类，在大多数情况下都是一种更好的选择，从而我们可以合理地遵循OO设计原则。
以MutableList<Int>为例，我们为其扩展?个exchange方法，代码如下：
fun MutableList<Int>.exchange(fromindex : Int, tolndex : Int) {
val tmp = this[fromlndex]
this[fromlndex] = this[tolndex]
this[tolndex] = tmp
}
MutableList<T>是 Kotlin 标准库Collections中的List容器类，这里作为recieviertype，exchange是扩展函数名。其余和 Kotlin 声明一个普通函数并无区别。
Kotlin 的this要比Java更灵活，这里扩展函数体里的this代表的是接收者类型的对象。这里需要注意的是：Kotlin 严格区分了接收者是否可空。如果你的函数是可空的，你需要重写一个可空类型的扩展函数。
我们可以非常方便地对该函数进行调用，代码如下：
val list = mutableListOf(1,2,3)
list.exchange(1,2)
扩展函数的使用如此方便，会不会对性能造成影响呢？我们以前面的MutableList<Int>.exchange为例，它对应的 Java 代码如下：
public final class ExSampleKt {
public static final void exchange(@NotNull List Sreceiver, int fromlndex, int tolndex) {
Intrinsics.checkParameterlsNotNull($receiver, "$receiver");
int tmp = ((Number)$receiver.get(fromlndex)).intValue();
Sreceiver.set(fromlndex, $receiver.get(tolndex));
Sreceiver.set(tolndex, Integer.valueOf(tmp));
}
}
可以看出，扩展函数被定义为了一个静态方法，而 Java 的静态方法的特点就是：独立于该类的任何实例对象，且不依赖类的特定实例，被该类的所有实例共享。此外，被public修饰的静态方法本质上也就是全局方法。
因此，我们可以得出结论：扩展函数不会带来额外的性能消耗。
一般来说，我们习惯将扩展函数直接定义在包内，例如前面的exchange例子，我们可以将其放在com.example.extension包下：
package com.example.extension
fun MutableList<Int>.exchange(fromindex : Int, tolndex : Int) {
val tmp = this[fromlndex]
this[fromlndex] = this[tolndex]
this[tolndex] = tmp
}
我们知道在同一个包内是可以直接调用exchange方法的。如果需要在其他包中调用，只需要import相应的方法即可，这与调用 Java 全局静态方法类似。除此之外，实际开发时我们也可能会将扩展函数定义在一个Class内部统一管理。
class Extends {
fun MutableList<Int>.exchange(fromindex : Int, tolndex : Int) {
val tmp = this[fromlndex]
this[fromlndex] = this[tolndex]
this[tolndex] = tmp
}
}
但是当扩展函数定义在Extends类内部时，你会发现，之前的exchange方法无法调用了（之前调用位置在Extends类外部）。
你可能会猜想，是不是它被声明为private方法了？但即便你尝试在exchange方法前加上public关键字也依旧无法调用到（实际上 Kotlin 中成员方法默认就是用public修饰的）。
是什么原因呢？借助 IDEA 我们可以查看到它对应的 Java 代码，这里展示关键部分：
public static final class Extends {
public final void exchange(@NotNull List Sreceiver, int fromlndex, int tolndex) {
Intrinsics.checkParameterlsNotNull(Sreceiver, "$receiver");
int tmp = ((Number)Sreceiver.get(fromlndex)).intValue();
Sreceiver.set(fromlndex, $receiver.get(tolndex));
Sreceiver.set(tolndex, Integer.valueOf(tmp));
}
}
我们看到，exchange方法上已经没有static关键字的修饰了。所以当扩展方法在一个Class内部时，我们只能在该类和该类的子类中进行调用。
或者，另一个解决方法是我们可以借助 Kotlin 的 with() 函数来解决：
object Extends {
fun MutableList<Int>.exchange(fromIndex:Int, toIndex:Int) {
val tmp = this[fromIndex]
this[fromIndex] = this[toIndex]
this[toIndex] = tmp
}
}
fun main() {
val list = mutableListOf(1,2,3)
with(Extends) {
list.exchange(1,2)
}
}
这里 Extends 定义为 object 单例，with(Extends) 函数的 {} 内部自动变成 Extends 实例的作用域范围，因此可以在其中正常的访问扩展函数了。如果 Extends 是一个已有的类，不方便改成 object 类，那么可以选择把扩展函数的定义包在一个伴生对象中：
class Extends {
companion object {
fun MutableList<Int>.exchange(fromIndex:Int, toIndex:Int) {
val tmp = this[fromIndex]
this[fromIndex] = this[toIndex]
this[toIndex] = tmp
}
}
}
fun main() {
val list = mutableListOf(1,2,3)
with(Extends) {
list.exchange(1,2)
}
}
这样同样能达到效果。
与扩展函数类似，我们还能为一个类添加扩展属性。比如我们想给 MutableList<Int> 添加一个判断和是否为偶数的属性sumIsEven：
val MutableList<Int>.sumlsEven: Boolean
get() = this.sum() % 2 == 0
就可以像扩展函数一样调用它：
val list = mutableListOf(2,2,4)
list.sumlsEven
但是扩展属性不支持默认值，如下写法会报错：
// 编译错误：扩展属性不能有初始化器
val MutableList<Int>.sumlsEven: Boolean = false
get() = this.sum() % 2 == 0
这是为什么呢？
其实，与扩展函数一样，其本质也是对应 Java 中的静态方法（我们反编译成 Java 代码后会看到一个getSumIsEven的静态方法）。由于扩展没有实际地将成员插入类中，因此对扩展属性来说幕后字段是无效的。
在Kotlin中，如果你需要声明一个静态的扩展函数，开发者必须将其定义在伴生对象(companion object）上。所以我们需要这样定义带有伴生对象的类：
class Son {
companion object {
val age = 10
}
}
现在Son类中已经有一个伴生对象，如果我们现在不想在Son中定义扩展函数，而是在Son的伴生对象上定义，可以这么写：
fun Son.Companion.foo() {
println("age = Sage")
}
这样，我们就能在Son没有实例对象的情况下，也能调用到这个扩展函数，语法类似于Java的静态方法：
fun main() {
Son.foo()
}
一切看起来都很顺利，但是当我们想让第三方类库也支持这样的写法时，我们发现，并不是所有的第三方类库中的类都存在伴生对象，我们只能通过它的实例来进行调用，但这样会造成很多不必要的麻烦。
已知有如下类：
class Son {
fun foo() = println("son called member foo")
}
假如我们不小心为Son写了一个同名的扩展函数：
fun Son.foo() = println("son called extention foo")
在调用时，我们希望调用的是扩展函数foo()，但是输出结果是成员函数的，不会符合我们的预期。
这表明：当同时存在同名的扩展函数和现有类的成员方法时，Kotlin将会默认使用类的成员方法覆盖同名扩展方法。
看起来似乎不够合理，并且很容易引发?些问题：我定义了新的方法，为什么还是调用到了旧的方法？
但是换一个角度思考，在多人开发的时候，如果每个人都对Son扩展了foo方法，是不是很容易造成混淆。对于第三方类库来说甚至是一场灾难：我们把不应该更改的方法改变了。所以在使用时，我们必须注意：同名的类成员方法的优先级总是高于扩展函数。
当在扩展函数里调用 this 时，指代的是接收者类型的实例。那么如果这个扩展函数声明在一个object内部，我们如何通过this获取到该object的实例呢？参考如下代码：
class Son {
fun foo() {
println("foo in Class Son")
}
}
object Parent {
fun foo() {
println("foo in Class Parent")
}
fun Son.foo2() {
this.foo()
this@Parent.foo()
}
}
fun main() {
val son = Son()
with(Parent) {
son.foo2()
}
}
这里我们可以用this@类名来强行指定调用的this。
Kotlin 标准库中有?些非常实用的扩展函数，除了之前我们接触过的apply、with函数之外，我们再来了解下let、run、also、takeIf。
先来看下run方法，它是利用扩展实现的，定义如下：
public inline fun <T, R> T.run(block: T.() -> R): R {
return block()
}
简单来说，run是任何类型T的通用扩展函数，run中执行了返回类型为R的扩展函数block，最终返回该扩展函数的结果。
在run函数中我们拥有一个单独的作用域，能够在其中定义一个新的变量，并且它的作用域只存在于run函数中。
fun testFoo() {
val nickName = "Prefert"
run {
val nickName = "YarenTang"
println(nickName) // YarenTang
}
println(nickName) // Prefert
}
这个范围函数本身似乎不是很有用，但是相比范围，还有一点不错的是，它返回范围内最后一个对象。
例如现在有这么一个场景：用户点击领取新人奖励的按钮，如果没有登录则弹出loginDialog，如果已经登录则弹出领取奖励的getNewAccountDialog。我们可以使用以下代码来处理这个逻辑：
run {
if (!islogin) loginDialog else getNewAccountDialog
}.show()
let：let和apply类似，唯一不同的是返回值：apply返回的是原来的对象，而let返回的是闭包里面的值。
public inline fun <T, R> T.let(block: (T) -> R): R {
return block(this)
}
data class Student(val age: Int)
class Kot {
val student: Student? = getStu()
fun dealStu() {
val result = student?.let {
println(it.age)
it.age
}
}
}
由于let函数返回的是闭包的最后一行，当student不为null的时候，才会打印并返回它的年龄。与run一样，它同样限制了变量的作用域。
also：它像是let和apply的加强版
public inline fun <T> T.also(block: (T) -> Unit): T {
block(this)
return this
}
与apply一样，它返回的是该函数的接收者
class Kot {
val student: Student? = getStu()
var age = 0
fun dealStu() {
val result = student?.also { stu ->
this.age += stu.age
println(this.age)
println(stu.age)
}
}
}
我将它的隐式参数指定为stu，假设student?不为空，我们会发现返回了student，并且总年龄age增加了。
值得注意的是：这里如果使用apply，由于它执行的block是T类型的扩展函数，this将指向stu而不是Kot，此处我们将无法调用到Kot下的age。
takeIf：如果我们不仅仅只想判空，还想加入条件，这时let可能显得有点不足。让我们来看看takeIf。
public inline fun <T> T.takeIf(predicate: (T) -> Boolean): T? {
return if (predicate(this)) this else null
}
如果我们想判断成年的学生再执行操作，可以这样写：
val result = student.takelf {it.age >= 18}.let {...}
我们发现，这与集合中的filter异曲同工，不过takeIf只操作单条数据。与takeIf相反的还有takeUnless，即接收器不满足特定条件才会执行。
除了以上这些，Kotlin中还有其他很多方便的扩展函数。
几年前，它被添加到Android支持库中，以取代Toast。它解决了一些问题并引入了一种全新的外观，基本使用方式如下：
Snackbar.make(parentView, message_text, duration)
.setAction(action_text, click_listener)
.show();
但是实际中使用它的API会给代码增加不必要的复杂性：我们不希望每次都定义我们想要显示消息的时间，并且在填充一堆参数后，为什么我们还要额外调用 show()？
著名的开源项目Anko拥有Snackbar的辅助函数，使其更易于使用并使代码更简洁：
snackbar(parentView, action_text, message_text) { click_listener }
其中一些参数是可选的，所以我们一般这么使用：
snackbar(parentView, "message")
它的部分源码如下：
inline fun View.snackbar(message: Int, @StringRes actionText: Int, noinline action: (View) -> Unit) {
Snackbar.make(this, message, Snackbar.LENGTH_SHORT)
.setAction(actionText, action)
.apply { show() }
}
如果想让它更短：
snackbar("message")
可以自己定义扩展函数：
inline fun Activity.snackbar(message: String) = snackbar(find(R.id.content), message)
inline fun Fragment.snackbar(message: String) = snackbar(activity.find(R.id.content), message)
而View并不一定附加在Activity上，我们要做出防御式判断，即：在我们尝试显示Snackbar之前，我们必须确保View的context属性隐藏了一个Activity实例：
inline fun View.snackbar(message: String) {
val activity = context
if (activity is Activity) {
snackbar(activity.find(android.R.id.content), message)
} else {
throw IllegalStateException("视图必须要承载在Activity上.")
}
}
比如，我们现在有一个判断手机网络是否可用的方法：
Boolean isConnected = NetworkUtils.isMobileConnected(context);
作为代码的使用者，我们更希望在调用时省略NetworkUtils类名，并且让isMobileConnected可以看起来像context的一个属性或方法。
我们期望的是下面这样的使用方式：
Boolean isConnected= context.isMobileConnected();
由于Context是Andorid SDK自带的类，我们无法对其进行修改，在Kotlin中，我们通过扩展函数就能简单地实现：
值得?提的是，在Android中对Context的生命周期需要进行很好地把控。这里我们应该使用ApplicationContext，防止出现生命周期不一致导致的内存泄漏或者其他问题。
除了上述方法，我们还有许多这样通用的代码，我们可以将它们放入不同的文件下。包括上面提到的Snackbar，我们也可以为其创建一个SnackbarUtils，这样会提供非常多的便利。但是需要注意的是，我们不能滥用这个特性。
对于Android开发者来说，对findViewById()这个方法?定不会陌生：在我们对视图控件操作前，我们需要通过findViewById方法来找到其对应的实例。
因为?个界面里的控件的数量可能会非常多，所以在 Android 开发早期我们通常都会看到一大片的findViewById(R.id.view_id)样板代码。而在老版本SDK中，在findBiewById获取到View之后，我们甚至还需要进行强制类型转换。
在Kotlin中我们可以利用扩展函数来简化：
fun <T : View> Activity._view(@ldRes id: Int): T {
return findViewByld(id) as T
}
调用：
loginButton = _view(R.id.btn_login);
nameEditText = _view(R.id.et_name);
现在调用起来是比较方便了，但是部分极简主义的读者可能会想：当前我们还是需要创建loginButton、nameEditText的实例，但是这些实例似乎只充当了?个“临时变量”的角色，我们依靠它进行一些点击事件绑定（onlick）、赋值操作后好像就没什么用处了。能不能将其也省略掉，直接对R.id.*操作呢？答案是可以，在Kotlin中我们可以利用高阶函数，做如下改动（此处以简化onclick为例子）：
fun Int.onClick(click: () -> Unit) {
// _view 为我们之前定义的简化版 findViewByld
val tmp = _view<View>(this).apply {
setOnClickListener {
click()
}
}
}
我们就可以这样绑定登录按钮的点击事件：
R.id.btn_login.onClick { println("Login...") }
可能有强迫症的读者会受不了R.id.xx这样的写法，并且每次都要写R.id前缀，某种情况下也会造成烦琐。
那还有更简洁的写法吗？答案是肯定的，Kotlin为我们提供了一个扩展插件：
apply plugin: 'kotlin-android-extensions'
btn_login.setOnClickListener {
println("MainKotlinActivity onClick Button")
}
虽然是省略了R.id.几个字符，但是引入是否会造成性能问题？ 让我们先对其反编译，看看其对应Java代码中是如何实现的：
public final class MainActivity extends BaseActivity {
private HashMap<Integer, View> _$_findViewCache;
protected void onCreate(@Nullable Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
this.setContentView(2131296283);
((TextView) this._$_findCachedViewById(id.label)).setText((CharSequence));
((TextView) this._$_findCachedViewById(id.label)).setOnClickListener((OnClickListener));
((Button) this._$_findCachedViewById(id.btn)).setOnClickListener((OnClickListener));
}
public View _$_findCachedViewById(int var1) {
if (this._$_findViewCache == null) {
this._$_findViewCache = new HashMap();
}
View var2 = (View) this._$_findViewCache.get(var1);
if (var2 == null) {
var2 = this.findViewById(var1);
this._$_findViewCache.put(var1, var2);
}
return var2;
}
public void _$_clearFindViewByIdCache() {
if (this._$_findViewCache != null) {
this._$_findViewCache.clear();
}
}
}
你会惊喜地发现，在第一次使用控件的时候，在缓存集合中进行查找，有就直接使用，没有就通过findViewById进行查找，并添加到缓存集合中。其还提供了$clearFindViewByIdCache()方法用于清除缓存，在我们想要彻底替换界面控件时可以使用。
注意：Fragment的onDestroyView()方法中默认调用了$clearFindViewByIdCache()清除缓存，而Activity没有。
虽然 KAE( Kotlin Android Extensions)很方便，但是很遗憾，由于某些原因，KAE 从 Kotlin 1.4.2 开始被官方宣布废弃，而在 Kotlin1.7 版本中直接移除了。。（具体可以看这里）
但是如果你喜欢，仍然可以自己模仿它的源码来实现一套自己维护。
或者，我们可以使用其他替代方案，比如viewbinding，在gradle添加如下配置：
android {
viewBinding {
enabled = true
}
}
然后使用效果同KAE一样，不过这和kotlin特性没多大关系了。（ 系统会为该模块中的每个XML布局文件生成一个绑定类）
已知我们有以下Java类：
class Base {
public void foo() {
System.out.println(("I'm Base foo!"));
}
}
class Extended extends Base {
@Override
public void foo() {
System.out.println(("I'm Extended foo!"));
}
}
Base base = new Extended();
base.foo();
我们声明一个名为base的变量，它具有编译时类型Base和运行时类型Extended。当我们调用时，base.foo()将动态调度该方法，这意味着运行时类型（Extended）的方法被调用。
当我们调用重载方法时，调度变为静态并且仅取决于编译时类型。
void foo(Base base) {
...
}
void foo(Extended extended) {
...
}
public static void main(String] args) {
Base base = new Extended();
foo(base);
}
在这种情况下，即使base本质上是Extended的实例，最终还是会执行Base的方法。
可能你会好奇，这和扩展有什么关系？我们知道，扩展函数都有一个接收器（receiver），由于接收器实际上只是字节代码中编译方法的参数，因此你可以重载它，但不能覆盖它。这可能是成员和扩展函数之间最重要的区别：前者是动态调度的，后者总是静态调度的。
为了便于理解，我们举一个例子：
open class Base
class Extended : Base()
fun Base.foo() = "I'm Base.foo!"
fun Extended.foo() = "I'm Extended.foo!"
fun main() {
val instance: Base = Extended()
val instance2 = Extended()
println(instance.foo()) // Output: I'm Base.foo!
println(instance2.foo()) // Output: I'm Extended.foo!
}
正如我们所说，由于只考虑了编译时类型，第1个打印将调用Base.foo()，而第2个打印将调用Extended.foo()。
如果我们在类的内部声明扩展函数，那么它将不是静态的。如果该扩展函数加上open关键字，我们可以在子类中进行重写（override）。这是否意味着它将被动态调度？这是一个比较尴尬的问题：当在类内部声明扩展函数时，它同时具有调度接收器和扩展接收器。
调度接收器和扩展接收器的概念
class X {
fun Y.foo() = " I'm Y.foo"
}
在上面的例子中，X是调度接收器而Y是扩展接收器。如果将扩展函数声明为open，则它的调度接收器只能是动态的，而扩展接收器总是在编译时解析。
这样说你可能还不是很明白，我们还是举一个例子帮助理解：
open class Base
class Extended : Base()
open class X {
open fun Base.foo() {
println("I'm Base.foo in X")
}
open fun Extended.foo() {
println("I'm Extended.foo in X")
}
fun deal(base: Base) {
base.foo()
}
}
class Y : X() {
override fun Base.foo() {
println("I'm Base.foo in Y")
}
override fun Extended.foo() {
println("I'm Extended.foo in Y")
}
}
fun main() {
X().deal(Base()) // 输出: I'm Base.foo in X
Y().deal(Base()) // 输出: I'm Base.foo in Y 即 dispatch receiver 被动态调度
X().deal(Extended()) // 输出: I'm Base.foo in X 即 extension receiver 被静态调度
Y().deal(Extended()) // 输出: I'm Base.foo in Y
}
聪明的你可能会注意到，Extended扩展函数始终没有被调用，并且此行为与我们之前在静态调度例子中所看到的一致。决定两个Base类扩展函数执行哪一个，直接因素是执行deal方法的类的运行时类型。
通过以上例子，我们可以总结出扩展函数几个需要注意的地方：
fun Context.loadImage(url: String, imageView: ImageView) {
GlideApp.with(this)
.load(url)
.placeholder(R.mipmap.img_default)
.error(R.mipmap.ic_error)
.into(imageView)
}
// ImageActivity.kt 中使用
...
this.loadlmage(url, imgView)
...
也许你在用的时候并没有感觉出什么奇怪的地方，但是实际上，我们并没有以任何方式扩展现有类。上述代码仅仅为了在函数调用的时候省去参数，这是一种滥用扩展机制的行为。
我们知道，Context作为“God Object”，已经承担了很多责任。
我们基于Context扩展，还很可能产生ImageView与传入上下文周期不一致导致的很多问题。
正确的做法应该是在ImageView上进行扩展：
fun ImageView.loadImage(url: String) {
GlideApp.with(this.context)
.load(url)
.placeholder(R.mipmap.img_default)
.error(R.mipmap.ic_error)
.into(this)
}
// Example usage
imageView.loadImage("https://example.com/image.jpg")
这样在调用的时候，不仅省去了更多的参数，而且ImageView的生命周期也得到了保证。
实际项目中，我们还需要考虑网络请求框架替换及维护的问题，一般会对图片请求框架进行二次封装：
object ImageLoader {
fun with(context: Context, url: String, imageView: ImageView) {
GlideApp.with(context)
.load(url)
.placeholder(R.mipmap.img_default)
.error(R.mipmap.ic_error)
.into(imageView)
}
}
// Example usage
ImageLoader.with(context, "https://example.com/image.jpg", imageView)
所以，虽然扩展函数能够提供许多便利，我们还是应该注意在恰当的地方使用它，否则会造成不必要的麻烦。