¿Los methods de extensión y las properties de extensión son malas prácticas?

Entonces, si los methods de extensión y las properties de extensión son realmente methods y properties estáticos. Y los methods y properties estáticos y los methods no son seguros para subprocesss y por lo tanto deben evitarse, entonces los methods de extensión y las properties de extensión son incorrectos.

Simplemente nos engañaron para hacer eso porque los códigos que escribimos aparecerán como bonitos o limpios, pero en cuanto a performance, no lo es.

¿Es esto cierto?

Depende de cómo haya escrito la function / propiedad de extensión. Si no editan ni acceden al estado compartido, es decir, si la propiedad y la function son funciones claras: no es una mala práctica.

Ejemplo 1:

fun String.countSpaces(): Int { return this.count { c -> c == ' ' } } 

Esta function funciona perfectamente en entornos de subprocesss múltiples, ya que String es inmutable.

Ejemplo 2:

 data class MutablePerson(val name: String, var speech: String) fun MutablePerson.count(nextNumber: Int) { this.speech = "${this.speech} ${nextNumber}" } 

Esta function muta speech propiedad del MutablePerson object MutablePerson y la operación de asignación no es atómica. Si se count en un object de diferentes subprocesss, el estado inconsistente es posible.

Ejemplo:

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

Posible resultado:

 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 

Así que las funciones de extensión y las properties de las extensiones no son malas prácticas, son solo como properties y methods en las classs: según cómo haya escrito, son seguras o no.

Los methods estáticos tienen su propia stack solo como methods de instancia. Por lo tanto, los vars temporales dentro de un método estático están en la stack al igual que, por ejemplo, los methods. los parameters que se entregan a un método estático pueden estar sujetos a problemas de subprocesamiento al acceder al estado compartido, pero esta es exactamente la misma situación que con los methods de instancia.

Piense en la enorme cantidad de classs de Util en Java con methods estáticos como una solución que Java no tiene funciones de extensión. No ha fallado nada con respecto al multi-threading.

También en los methods de extensión C # están detrás de los methods estáticos de la escena y no causa ningún daño, consulte Cómo se implementan los methods de extensión internamente.

Como dijo, las funciones de extensión se resuelven estáticamente. Entonces, si comienzas a usar funciones de extensión como una forma de hacer classs de utilidad, entonces es una mala práctica.

En Java, la class Utils suele ser una mala práctica, no solo por la security de los hilos, sino también porque pueden ser un olor codificado por el mal layout y porque son difíciles de probar.

El principal problema con los methods estáticos es que no se pueden burlar (al less con Mockito), por lo que no podrá probar el código.

Pero, si usa funciones de extensión para tareas pequeñas y aisladas que no necesitan ser probadas, entonces no es una mala práctica (como ayuda para Tostadas, Registros …)

  • Cómo acceder a una vista desde el layout especificado en headerLayout de NavigationView usando Kotlin en Android
  • La function de extensión no crea un nuevo object Observable
  • findViewById ClassCastExcpetion
  • ¿Cómo colocar una extensión de Kotlin en un file de class?
  • Kotlin - Extensión para la class final
  • El resultado es el mismo, pero el caso de testing no pasa en la testing unitaria
  • ¿Funciones de extensión Kotlin contra funciones miembro?
  • Acceso a la function de extensión de Kotlin Campo privado de Java
  • ¿Se debe evitar nombrar una function igual que una class existente en Kotlin? ¿Por qué?
  • lanza Exception en un método con Kotlin
  • En kotlin, cómo devolver una instancia definida por un parámetro de class genérico