Everything in Kotlin is slick and elegant— you never have to write unnecessary code, and the primitive language constructs just work. But the dichotomy between mutable collections and immutable collections feels like something that can be avoided. The fact that it’s such an integral part of the language must point to something deeper.

The simple, one-line explanation is this:

Mutable and immutable collections individually expose useful features that can’t co-exist in a single interface. Mutable collections are mutable, while immutable collections are covariant.

If that doesn’t make sense to you, don’t worry. The rest of this article was written to explain it to you!

Type Hierarchy

We need to establish some important things about the type of hierarchy before moving on.

Assign-ability

Consider the following variable:

Although the variable is declared with type Shape, you can actually store an object of type Rectangle in it. That’s because Rectangle is a subtype of Shape, so it will have at least all of the properties/fields/methods of Shape implemented.

Therefore, this is valid:

Which brings us to the first important point you need to remember:

When assigning an object to a variable, the variable’s type must be a supertype of (or the same as) the type of the incoming object.

It is important to emphasize the distinction between the type of the variable and the type of the object. The variable myShape ‘looks’ like a Shape, but actually holds a Rectangle.

In this sense, the type of the variable defines an interface. When you interact with myShape, you interact with the Rectangle, but you only do so in Shape-specific ways.

#programming-languages #kotlin-collection #kotlin #design-patterns #object-oriented