A long list of arguments is an indicator for complexity.
If a constructor has many arguments, it might be doing too much.
We can’t define a hard number for what “many” means here. For example, a
OrderPriceCalculator might be a hundred lines of code while needing no constructor arguments at all.
Opposing that, an
OrderCreatormight be more of a step-by-step instruction which delegates all the “real” work to other objects. This way you can end up with a class with only 20 lines of code in its methods, but 7 constructor arguments. In that case, splitting it up further would not improve the project’s overall readability.
So, for a quick check, comparing the amount of constructors to the overall class size is a pretty decent indicator.
If a method has many arguments, it might be doing too much.
We are stating the obvious here, but methods with more arguments tend to be more complex than methods with less arguments. In order to make a method as easy to understand as possible, we have to make it have as little arguments as possible.
Obviously we can’t just remove arguments which the methods needs to work, but it might be possible to split the method up.
Another thing we can do is to take a number of arguments and put them into their own class. This does not really change how anything works. The only change elsewhere is that we create a new instance of that class before we pass it to the method, but it does increase the readability of the method signature greatly.
Plus, as a bonus, this often makes it apparent that (part of) the method can be moved to this new class instead, creating a clean and easier to understand object.
Next Article: Errors are not Exceptions