The regular section "someone is wrong on the internet" returns. We're now talking about an article of the same name on Medium, which the author first posted in r/Kotlin and r/androiddev, I got indignant and passed by, and yesterday Android Weekly sent it in their newsletter and that triggered me. I still somehow consider AW a valuable resource that doesn't post outright craziness.
The person writes a wall of text describing the task like this: there's some class, we want to create its instance passing only the necessary parameters. What are our options? Well, he says, you can overload constructors. Crap turns out? Yes, you have to write a lot of code. Well, here's a solution to this problem - Builder Pattern from GOF, in its most Java manifestation in the world. This is when you don't call the constructor of the object itself, but some setters of a special builder, and then at the end you call some build() on the builder, which creates the instance.
He says that this way you can keep the class itself immutable, you can keep one constructor, and you don't need to specify unnecessary parameters, encapsulated the logic of instance creation. All pluses. Well, except for the fact that all our input validity checks have now moved from compile-time to runtime. And except for the fact that we duplicated the enumeration of all fields 3 times.
The author appeals to examples of Notification, AlertDialog. Says - well, there it is, there's such a thing in Android, what a good pattern! Hello, they're written in Java, they simply have no choice. If I got paid every time I forgot to call some build, show or create method...
What if I told you that you can write a data class with default parameters and when calling its constructor use named parameters to specify exactly what you want to specify? Surprising, yes? Delete all this wall of text and replace it with 5 lines where you just call a constructor with default parameters. No, that's some nonsense.
I'll throw in some obvious architectural remarks on top. First - if you have too many parameters in a structure, it's time to decompose them into groups. Second - if you want to create an object that's partially filled, you're doing something wrong, think again, create separate parts instead and compose from them when all parts are ready.
What did I even read, lord. A model of bad advice simply, don't do this.
The approach described by the author, actually, has a place left only when you're writing some DSL (conditional StringBuilder) or a library (conditional OkHttp), but this is already, you could say, something else. The author is not about this at all.