Recently during a code review I came across code, written by a new colleague, which contains a pattern with a smell. I suspect that my colleague's decisions are based on rules proposed by the famous Clean Code book (and perhaps by other similar books as well).

It is my understanding that the class constructor is entirely responsible for the creation of a valid object and that its main task is the assignment of an object's (private) properties. It could of course occur that optional property values may be set by methods other than the class constructor, but such situations are rather rare (although not necessarily wrong, provided that the rest of the class takes into account such a property's optionality). This is important, because it allows to ensure that the object is always in a valid state.

However, in the code that I encountered, most property values are actually set by other methods than the constructor. Values that result from calculations are assigned to properties to be used inside several private methods throughout the class. The author seemingly uses class properties as if they were global variables that should be accessible throughout the class, instead of parameterizing these values to the functions that need them. Additionally, the methods of the class should be called in a specific order, because the class won't do much otherwise.

I suspect that this code has been inspired by the advice to keep methods short (<=5 lines of code), to avoid large parameter lists (<3 parameters) and that constructors must not do work (such as performing a calculation of some sort that is essential for the validity of the object).

Now of course I could make a case against this pattern if I can prove that all kinds of undefined errors potentially arise when methods are not called in a specific order. However, I predict that the response to this is going to be adding validations which verify that properties must be set once methods are called that need those properties to be set.

I would however rather propose to completely change the code, so that the class becomes a blue print to an actual object, rather than a series of methods which should be called (procedurally) in a specific order.

I feel that the code that I encountered smells. In fact, I believe there exists a rather clear distinction as to when to save a value in a class property and when to put it into a parameter for a different method to use - I don't really believe they can be alternatives to one another. I am looking for the words for this distinction.