I have found the following heuristic to be quite useful in most cases.
- The places where you instantiate the object, and where you call its methods are separated, both in time, and in scope.
- The best design emerges when you define the injection of parameters as early as possible, early meaning with respect to the flow of your code.
- If, in your design flow, you get to know the parameter value at the construction time of your object, you define it as an input to the constructor, otherwise you have to define it as an input to the method.
If you take the Premise as an axiom of good object-oriented design, then the Theorem may help guide your design, given that you actually have one at hand (and not blindly naming objects just for the sake of the class names).
In its TL;DR version, this answer reads: if the parameter value becomes known at the very latest moment during your design, just put it in the method. If you knew it any earlier in advance, take it out, either in the constructor, or in another method.
Point class, with a
distanceFrom method, to calculate the distance from another point. Does it make sense to have the method
distanceFrom(x, y, xOther, yOther)? Nope, because you knew x and y of the point upon its construction, so you should have passed that to the constructor. So the proper method is
distanceFrom(x,y) (or, more likely,
When you calculate days away of a Person, you have to subtract two timestamps. One of them is now. The other one of them is sometime in the past. The past timestamp was known earlier so the optimal design is to avoid putting it in the method. Find some way to acquaint your
Person object with the past timestamp as early as possible, preferably the moment it becomes known, i.e., possibly, in the constructor or, if you want to change it along the lifetime of your
Person object, create another method along the lines of
Person.cameBack(timestamp), so that the Person can mark the timestamp to use it later for the