Martin Fowler’s seminal 1999 book Refactoring includes a chapter with Kent Beck on “code smells”. Code smells, they say, are “certain structures in the code that suggest (sometimes they scream for) the possibility of refactoring”. One of the code smells they talk about is the Data Clump.
Often you’ll see the same three or four data items together in lots of places: fields in a couple of classes, parameters in many method signatures. Bunches of data that hang around together really ought to be made into their own object.
They give a quick test for a data clump: if you delete one of the data values, would the others make sense?
This is a good test, and in today’s article, I’d like to propose another useful way to detect data clumps. To be honest, I thought I’d read this elsewhere, but I’ve done some deep googling and scouring of the original texts, and I can’t find any reference to it anywhere. If you do find a good reference to this thought technology, please be sure to reach out. Update: I found it. In Sandi Metz’s 2014 RailsConf talk, All the Little Things, she discusses this at ~22:30.
If two or more instance variables (or parameters in a parameter list, etc) have a similar prefix or suffix, they’re probably a data clump. They should be associated with each other more closely than being placed next to each other.
Three distinct examples of this stick out to me.
The second app I ever made, Fireside, was a podcast player, and (among its many mistakes) it had the following in its Podcast model:
@property (nonatomic, copy) NSString *filePath;
@property (nonatomic, assign) BOOL isDownloaded;
@property (nonatomic, assign) BOOL fullyDownloaded;
@property (nonatomic, strong) NSDate *expirationDate;
@property (nonatomic, copy) NSString *streamedCopyFilePath;
@property (nonatomic, assign) BOOL streamedCopyIsDownloaded;
@property (nonatomic, assign) BOOL streamedCopyFullyDownloaded;
@property (nonatomic, strong) NSDate *streamedCopyExpirationDate;
(Pardon the Objective-C, this code is from 2011.)
In the fullness of time, it’s so obvious that this is a bad model. These four properties, filePath, isDownloaded, isFullyDownloaded, and expirationDate, should live on a new class, maybe called DownloadDetails, which would also serve as a nice home for any logic around this data, such as if the download is past its expiration date.
(If you’re wondering why there are two boolean values for the downloaded state, fullyDownloaded represents if the podcast is downloaded from the first byte to the end, and isDownloaded represents if the podcast has been downloaded from any point, such as a point the user has scrubbed to, to the end. These days, I’d probably make it an enum with three states: not downloaded, downloaded, and fully downloaded, but that’s another post.)
The matching prefixes on the properties are the clue here that concepts are duplicated. Seeing them now, they’re begging for refactoring.
Another classic example of similar prefixes can be found in the view layer. Raise your hand if you’ve done this one:
let headerContainer = UIView()
let headerBackgroundImage = UIImageView()
let headerAvatarImage = UIImageView()
let headerTitle = UILabel()
let headerDescription = UILabel()
If you’re making a bunch of views that all have the same prefix, chances are they represent a logical unit. In this case, they even have a common superview, the headerContainer. Are you really sure you’re not going to reuse these 5 views and their layout? Make the HeaderView class, don’t be lazy. (H/t to Rosa McGee for this example, and John Sundell for a blog post in a similar vein.)
The last example I want to look at happened recently, and was the impetus for this blog post. The original code wasn’t the worst code, but it was sprinkled into 600 lines of unrelated singleton code:
private var sequenceStartTime: Date?
private var sequencePauseTime: Date?
// 150 lines of other stuff
func startSequenceTimer() {
self.sequenceStartTime = Date()
}
func pauseSequenceTimer() {
self.sequencePauseTime = Date()
}
// 50 lines of unrelated responsibilities
func resumeSequenceTimer() {
let pauseEndTime = Date()
let duration = pauseEndTime.timeIntervalSince1970 - sequencePauseTime.timeIntervalSince1970
self.sequenceStartTime = Date().addingTimeInterval(duration)
}
// 100 more lines of just whatever
func calculateDuration() {
let sequenceEndTime = Date()
let duration: Double
if let startTime = sequenceStartTime {
duration = Double(sequenceEndTime.timeIntervalSince1970 - sequenceStartTimetimeIntervalSince1970) / 1_000
} else {
duration = 0.0
}
return duration
}
This is clearly its own responsibility, and the start and end time variables are the first clue into that. This singleton doesn’t care about how to pause the timer or calculate the current running duration, it just needs to be able to pause a timer. This eventually became its own type and the two instance variables became the central identity of the type:
struct Milliseconds {
let rawValue: Int
}
protocol Clock {
func now() -> Milliseconds
}
class Stopwatch {
let clock: Clock
private var startTime: Milliseconds?
private var pauseTime: Milliseconds?
// ...
}
The Clock protocol also enables the type to be tested, which wasn’t possible before. (H/t to Olivier Halligon showing me how to test this class.) The tests also enabled me to fix a few bugs in the original code. (If you’re wondering what kinds of bugs, look at the original code: what happens if you’ve currently paused and you try to check the duration?)
Extracting data clumps is a great way to find hidden classes and responsibilities within your code, and a great way to locate their hiding spots is to look at the language you use to define the variables. If there is a relationship between the language of the two properties, perhaps there is a deeper relationship is waiting to be drawn out as well. Expressing those relationships explicitly can lead to cleaner, more testable, and more reusable code.
