Member-only story
The Case Against Immutable Objects in Swift
This is one design pattern you definitely don’t want to use. Here’s why.
Design patterns come and go, and one of the fads currently ascendant in the iOS/Swift programming world is the concept of Immutable Objects.
To quote Wikipedia:
In object-oriented and functional programming, an immutable object is an object whose state cannot be modified after it is created.
Pretty straightforward. Immutable objects are considered to be desirable because anyone who depends upon any given instance of an object can be assured that that object won’t change on them.
That can minimize bugs and make code easier to understand and to reason about. All good things. And functional programmers are fond of them because they’re one of the core building blocks found on the road to writing pure functions.
But immutability often comes with a fairly stiff price, and that price is that it often requires a lot of boilerplate code.
Not to mention that in Swift we’re actually solving the wrong problem entirely, but I digress. More on that later.
Let’s tackle the boilerplate code issue first.
