Parámetros de Clase abstracta vs. Lambda

Como kotlin tiene un soporte tan bueno para lambdas, comencé a usar lambdas como parameters de constructor para classs abstract lugar de declarar abstract val/fun .

Es más conciso en mi opinión, especialmente porque se infiere el tipo de val get.

¿Cuáles son las desventajas de esto?

 abstract class AbstractListScreen<T> ( val data: Set<T>, val filterators: (T) -> Set<String> ) { fun open() { /* ... */ } } class OrderListScreen : AbstractListScreen<Data>(data = setOf(), filterators = { setOf(it.toString()) } ) { fun someEvent() { /* ...*/ } } 

  1. En su ejemplo, cada instancia de OrderListScreen creará su propia instancia de filterators del tipo de function (T) -> Set<String> . Esto tiene una sobrecarga de time de ejecución adicional tanto en memory como en performance cuando se compara con las funciones abstractas y sus modificaciones que se almacenan en la definición de tipo en time de compilation.
  2. Los filters pnetworkingeterminados se pueden almacenar en una propiedad para networkingucir esta sobrecarga en time de ejecución:

     class OrderListScreen : AbstractListScreen<Data>(data = setOf(), filterators = defaultFilterators ) { companion object { val defaultFilterators: (Data) -> Set<String> = { setOf(it.toString()) } } fun someEvent() { /* ...*/ } } 

    Sin embargo, cada instancia de OrderListScreen seguirá teniendo su propia reference a defaultFilterators que aún es una sobrecarga de time de ejecución adicional (aunque marginal a less que tenga muchas instancias de estos types).

  3. Los types de funciones tales como (T) -> Set<String> pueden tener parameters con nombre (ej. (element: T) -> Set<String> ) pero actualmente los IDEs como IntelliJ IDEA no usan esos parameters nombrados en la documentation generada o códigos. por lo tanto, dicha información se pierde al crear subclasss, etc. Los IDE usan parameters con nombre en la documentation generada y en los códigos para las funciones abstractas.

  4. No puede (actualmente) asociar documentation directamente con el parámetro de tipo de function que puede hacer con funciones abstractas.

Cuando se intenta contabilizar la sobrecarga en time de ejecución, el código no se ve muy diferente cuando se usan funciones abstractas, se elimina la sobrecarga en time de ejecución y se mejora el soporte IDE actual para los fragments de código generados, documentation, etc.

 abstract class AbstractListScreen<T>(val data: Set<T>) { abstract fun filterators(element: T): Set<String> fun open() { /* ... */ } } class OrderListScreen : AbstractListScreen<Data>(data = setOf()) { override fun filterators(element: Data): Set<String> = setOf(element.toString()) fun someEvent() { /* ...*/ } }