所以如果扩展方法和扩展属性真的是静态方法和属性。并且静态方法和属性和方法不是线程安全的,因此应该避免扩展方法和扩展属性是不好的。
我们只是被欺骗了,因为我们编写的代码看起来很漂亮或干净,但在性能方面却不是。
这是真的?
所以如果扩展方法和扩展属性真的是静态方法和属性。并且静态方法和属性和方法不是线程安全的,因此应该避免扩展方法和扩展属性是不好的。
我们只是被欺骗了,因为我们编写的代码看起来很漂亮或干净,但在性能方面却不是。
这是真的?
这取决于您如何编写扩展函数/属性。如果他们不编辑或访问共享状态,即如果属性和功能是明确的功能:这绝对不是坏习惯。
示例 1:
fun String.countSpaces(): Int {
return this.count { c -> c == ' ' }
}
此函数在多线程环境中完美运行,因为String
它是不可变的。
示例 2:
data class MutablePerson(val name: String, var speech: String)
fun MutablePerson.count(nextNumber: Int) {
this.speech = "${this.speech} ${nextNumber}"
}
这个函数改变对象speech
的属性MutablePerson
并且赋值操作不是原子的。如果count
将在不同线程的一个对象上调用 - 可能存在不一致的状态。
例子:
fun main(args: Array<String>) {
val person = MutablePerson("Ruslan", "I'm starting count from 0 to 10:")
(1..10).forEach { it ->
Thread({
person.count(it)
println(person.speech)
}).start()
}
Thread.sleep(1000)
println(person.speech)
}
可能的输出:
I'm starting count from 0 to 10: 1
I'm starting count from 0 to 10: 1 3
I'm starting count from 0 to 10: 1 3 4
I'm starting count from 0 to 10: 1 3 4 2
I'm starting count from 0 to 10: 1 3 4 2 5
I'm starting count from 0 to 10: 1 3 4 2 5 8
I'm starting count from 0 to 10: 1 3 4 2 5 6
I'm starting count from 0 to 10: 1 3 4 2 5 6 7
I'm starting count from 0 to 10: 1 3 4 2 5 6 7 9
I'm starting count from 0 to 10: 1 3 4 2 5 6 7 9 10
I'm starting count from 0 to 10: 1 3 4 2 5 6 7 9 10
所以扩展函数和扩展属性是不错的做法,它们就像类中的属性和方法:取决于你如何编写它们线程安全与否。
静态方法和实例方法一样有自己的堆栈。因此,静态方法中的临时变量就像实例方法一样在堆栈上。传递给静态方法的参数在访问共享状态时可能会遇到线程问题,但这与实例方法完全相同。
将 Java 中具有静态方法的大量 Util 类视为 Java 没有扩展函数的解决方法。关于多线程,那里没有任何问题。
同样在 C# 中,扩展方法在幕后是静态方法,它不会造成任何伤害,请参阅扩展方法是如何在内部实现的
正如您所说,扩展功能是静态解决的。因此,如果您开始使用扩展函数作为制作实用程序类的一种方式,那么这是一种不好的做法。
在 Java 中,Utils 类通常是一种不好的做法,不仅因为线程安全,而且因为它们可能是糟糕设计的代码味道,而且它们很难测试。
静态方法的主要问题是它们不能被模拟(至少使用 Mockito),所以你将无法测试你的代码。
但是,如果您将扩展函数用于不需要测试的小型、孤立的任务,那么这根本不是一个坏习惯(比如 Toasts、Logs 的助手......)