rialvalue.com No Flex No Fun

Some thoughts on constructor and method parameters

I consider a best practice to keep to the minimum the number of arguments a method accepts. As uncle Bob explains in his “Clean code” book we should always favour niladic (no arguments), monadic (1 argument) or dyadic (2 argument) methods and avoid whenever possible methods with more than 3 arguments, if not possible we should be able to clearly justify them.

The higher number of arguments a method accepts the harder it’ll be to read, understand and test.

When a method needs too much arguments, it is normally a sign of:

1. Poor encapsulation
2. The method is doing more than one thing, breaking the Single Responsibility principle. The arguments define what the method will do, they define and change the method execution path. (i.e. flag methods)
3. Method signatures are harder to read and it’s easier to introduce errors by swapping the order of parameters (specially if they are of the same type). (link to FB issue to highlight parameters. i.e. assertEquals();)
4. Method parameters are all part of the same concept and could be encapsulated in an object with its own type.
5. Arguments belong to different levels of abstraction and are harder to understand.

To reduce the number of arguments in class methods you can consider different techniques depending on what the exact problem is in each case:

1. Create specialised objects that wrap several parameters. i.e. x, y could be a Point instance.
2. Transform method arguments into class properties so that they don’t need to be passed between methods.
3. Create different methods or strategies to fork the behaviour instead of using flag parameters
4. Use factory methods and builders.

All points above can even get worse when overusing optional parameters, which lot of people use to alleviate the lack of method and constructor overloading in ActionScript3 instead of using Builders, Factories of creating different named methods.

If we focus on constructors I think they should only accept:

1. Required parameters for the object to be properly initialised.
2. Optional invariant parameters. Parameters that can’t be changed during the life of the object and that thus need to be specified during born.

Let’s consider the typical Person object with a name, surname, age and a unique invariant Id. We define a constructor with 1 required argument and 3 optional ones:

You could create different instances like:

The code above will compile fine, the compiler won’t complain at all since all declarations are right, but there’re several data integrity errors here, errors that are normally very hard to find and isolate. i.e. p3 is setting the address as the surname. p4 is swapping the surname and the address.

In this case, the Person type and the data might be self explanatory, but there are a bunch of other cases that are not. Having cluttered constructors with lots of optional parameters is quite common when dealing with Custom Events.

What would be interesting is to be able to pass the optional parameters in a named way, removing the order constraint while making the solution more readable, developer friendly and robust to changes:

This solution is a kind of Buider pattern implemented in a fluent way, a train wreck. It’s also somehow mimicking named parameters in other languages. The nice things I really like about this syntax is:

1. It’s a compact expression. It can be written in just one line.
2. The order of the optional parameters is not important anymore.
3. It’s easy to read and prevents parameter swapping. In some cases it can also be read as a natural language phrase.
4. In case of invariant optional parameters the builder can hide the implementation in the build method.
5. It doesn’t break Demeter’s law. Although implemented as a train wreck, each method is applied on the same object.

As mentioned above a common scenario where you could apply this technique is when dealing with custom events. Imagine you want to implement CRUD operations in terms of Persons. You could have:

This implementation would allow you to reuse the same PersonEvent for the different operations without cluttering the constructor with all the different permutations of optional and required parameters in a scalable way. Another option in this case would be using static factory methods (but this won’t solve the optional parameters mess).