The fiasco of configuration objects

There is this commonly followed programming rule that says that parameter lists must be short.

Nobody wants to see a constructor with more than 2 arguments right?

Right?

Well, let me tell you what annoys me more than that. Start writing the type constructor and not seeing the suggestion for what parameters it needs, specially when you know that at least it accepts one argument of type X.

The usual scenario:

• Start typing View(title...
• Xcode be like ¯\_(ツ)_/¯
• Lose time going to the documentation and seeing View(configuration: View.Config)
• Lost more timing going to the Config configuration to know what’s configurable.
• Go back to your code and create and configure 2 objects instead of 1.
• 🤦🏻‍♂️

This may be ideal in some scenarios and other languages, and Swift making it so easy to create lightweight types makes it an ideal technique.

But I think that we can rely in another Swift feature that gives us the best of both worlds: default arguments.

With default arguments we have the advantages of keeping the configuration in the constructor (where it should be) and we are still able to evolve the arguments without breaking the usages. And if you just want to use one or two parameters you can!

This is one of those posts that I like to write just to raise the concern against dogma. Don’t be confused, this is not trying to impose a new rule that you must follow, quite the opposite!

Swift gives us (better) alternatives to old solutions. We should try to use them before deciding to go back to the old habits.