De Java a Kotlin

Capítulo 15. Colecciones encapsuladas a alias de tipos

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: [e-mail]

En Java, encapsulamos colecciones de objetos en clases para controlar las operaciones de mutación y adición. Controlar la mutación es menos preocupante en Kotlin, y podemos utilizar funciones de extensión para añadir operaciones. ¿Cómo serían mejores nuestros diseños sin la encapsulación, y cómo lo conseguimos?

En Capítulo 6 vimos las diferencias entre los granos de Java y Kotlin en lo que respecta a las colecciones. Las interfaces de colección de Java, en consonancia con sus raíces orientadas a objetos, son fundamentalmente mutables, mientras que Kotlin trata las colecciones como tipos de valor. Como vimos, si mutamos colecciones compartidas, podemos meternos en todo tipo de problemas. Podríamos evitar esos problemas no mutando las colecciones compartidas ("No mutar colecciones compartidas"), pero en Java eso es difícil de hacer cuando esos métodos add y set están a sólo un autocompletado de distancia. En lugar de convención y disciplina, la mayor parte del código Java opta sensatamente por el enfoque más seguro de simplemente no compartir colecciones en bruto. En su lugar, las colecciones se ocultan dentro de otro objeto.

Aquí tienes, por ejemplo, un Route en Travelator:

public class Route {
    private final List<Journey> journeys; 

    public Route(List<Journey> journeys) {
        this.journeys = journeys; 
    }