## Single responsibility principle : a Kata

Some time ago I was browsing on http://rubyquiz.com/ and found a really interesting exercise there. It’s name is Getting to 100. The rules are quite simple:

1. You are given the sequence of numbers 123456789
2. Each number in the interval [1-9] has to be present in the sequence
3. Each number must appear once and only once
4. Numbers should be in increasing order
5. You are given three operators: two minuses and one plus that you have to insert between those numbers
6. The resulting equation should be give 100

## Composite Design Pattern Kata

Today’s post is nothing elevated, just two examples from which one can understand this powerful design pattern.

First, let’s do a quick recap, how the pattern actually looks like:

(if you’re new to design patterns, please find a detailed description here)

The exercises are the following (note that the second one usually looks easier, because it’s easier to imagine. However, you are gonna have a harder time if you want to do that properly using TDD. Mocking recursive structures is not the easiest thing to do):

1. Implement an application that can draw(no, you don’t really have to draw, just implement the data structures) pictures using rectangles and circles. A picture can be made from primitives (rectangles and circles), primitives combined with other pictures (one or more primitives and at least one other picture – which is composed of primitives), and several pictures combined. (Spoiler: circles and rectangles are leaves, pictures are composite objects)
2. Implement an application that can compute (yes, you really have to compute) the size of a directory. The size of a directory is equal to the sum of all the files it contains plus the size of its subdirectories. (Hint: you might want to wrap java.io.File objects inside your Leaf and Composite classes. Spoiler: in this case plain files are leaves, directories are composites).

You can find a solution to the second problem here (implementation in Java, unit tested with JUnit and Mockito).

## Builder vs. Large arg-list constructor

Today I was browsing one of our module’s code. I wasn’t looking for anything in particular, I just wanted to familiarize myself with that part of the system. However, I found something strange; the code was full of object constructions like:

private MyObject myObject = new MyObject(null, null, "", "", importantData, importantData2);

You might say, yes, this class does way too many things if it takes this many arguments. Believe it or not, it actually made sense to keep those data together. The real problem was passing around null and dummy values across the system. And the situation was even worse in case of unit tests.

Let’s see a toy example – a.k.a. code that’s not confidential. We consider the class:

import java.util.Date;

public class User {

private String nickName;
private Date lastOnline;
private Balance balance;

this.nickName = nickName;
this.lastOnline = lastOnline;
this.balance = balance;
}
}

For the sake of the example, let’s suppose we have object constructions like:

User user = new User("tamasgyorfi", "lotsOfAsterisks", "", null, null, null);

User anotherUser = new User("", "", "chaster", new Date(), null, null);

Well, this is 100% functional, but not that clean. Null values and empty strings make these lines sort of “noisy”. How do we make this cleaner? I think in such situations it is worth to give Builder Design Pattern a try, as it makes object construction more straightforward.

This is how I usually do it, in six easy steps: I

1. create a new class and name it UserBuilder (I like to add the word Builder so others know what they’re facing)
2. copy all the fields of the object under construction into the builder
3. (as far as I know) Eclipse is not able to generate the methods I need, so I have it generate all the setters for the fields
4. with find/replace I replace all the words “set” with “with”. Also replace the return types from void to UserBuilder
5. have all the methods return this
6. create a method named “build”. It does the actual construction and returns the object constructed.

After step 6, we have something like this:

import java.util.Date;

public class UserBuilder {

private String nickName;
private Date lastOnline;
private Balance balance;

return this;
}

return this;
}

public UserBuilder withNickName(String nickName) {
this.nickName = nickName;
return this;
}

public UserBuilder withLastOnline(Date lastOnline) {
this.lastOnline = lastOnline;
return this;
}

return this;
}

public UserBuilder withBalance(Balance balance) {
this.balance = balance;
return this;
}

public User build() {
balance);
}

}

So we can replace the object constructions mentioned above with these calls:

UserBuilder builder = new UserBuilder();