Over a million developers have joined DZone.

Legacy Code: The Case of the Construction Blob

DZone's Guide to

Legacy Code: The Case of the Construction Blob

· Java Zone ·
Free Resource

Java-based (JDBC) data connectivity to SaaS, NoSQL, and Big Data. Download Now.

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?

Connect any Java based application to your SaaS data.  Over 100+ Java-based data source connectors.


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}