Legacy Code: The Case of the Construction Blob
Exercising the application of some principles from “The Case of the Construction Blob” from Michael Feather’s Working Effectively with Legacy Code, I used Supersede Instance Variable to avoid creating a certain, troublesome object in the constructor of a non-legacy class under test.
Wait… what’s that? Non-legacy?
Yep. The class in question was already under test — developed with TDD and only a week ago — but I found myself refactoring and could not avoid creating the object in the class’s constructor. I have mixed feelings about it, but I won’t lose any sleep.
During this process, I noticed that Feathers doesn’t seem to like either of his solutions to the dependencies-in-constructors problem. For a few minutes I went back and forth trying to decide what to do. Here’s why.
In “The Case of the Construction Blob” Feathers states:
… we can use Extract and Override Factory Method (350) on code in a constructor …but … in general, it isn’t a good idea.
He then goes on to outline Supersede Instance Variable as a second option and writes:
We write a setter on the class that allows us to swap in another instance after we construct the object. … I don’t like to use [it] unless I can’t avoid it.
After re-reading this section, given the parts I emphasized above, I half-expected him to outright say “if you have this problem, you have a bigger problem” but he didn’t.
So, am I reading this right? Does he not like either solution? Is there some third option I’m missing that he does like?
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)