An Object is a Choice.

My favorite class design principle is The Single Responsibility Principle (SRP). The SRP states that a class should have only one reason to change. As principles go, SRP is tricky. It’s easy to see if you are breaking The Dependency Inversion Principle (DIP) or the Open/Closed Principle (OCP) but what are ‘reasons to change’ and how are we supposed to understand what they are in advance?

One heuristic that I use is to think of an object as a choice. Whenever we sit down to write a class we make a series of choices. We may choose to use one library over another or we may use one algorithm or another but the fact is, many of these choices are significant and the best thing that we can do is be conscious of the fact that we are making them. When we are, we often find places where objects help. Here’s an example.

A while back, I was working on a little code duplication detector for Java. It read Java source, line by line, and attempted to match it against snippets of source it had already seen. One of the key questions you have to ask yourself whenever you are doing this sort of matching is what criteria you’ll use for a match. It’s easy to demand exact matches when we want to detect duplication, but that’s too conservative: it misses code chunks that differ only by whitespace.

One way to do whitespace-invariant matching is to transform the lines as they come in. We can replace every run of whitespace with a single space. Once we've done that transformation on a line we can match it against other lines that we've transformed the same way.

Armed with that thought, I wrote a test:

public void testTransformLine() {
    String source = "class   Account {\tpublic void test(){}}";
    assertEquals("class Account { public void test(){}}", DuplicationDetector.transformLine(source));
}

And some code to make it pass:

public class DuplicationDetector {
    ...
    static String transformLine(String line) {
        return line.replaceAll("\\s+", " ");
    }
}

With that code in place, I ran my duplication detector on an old code base and found some duplication, but then I had some other questions. For instance: how much duplication could I find if I made the detector replace every identifier and keyword with the character 'x'? If I did that, I’d have a detector that ignored symbol information and looked directly at patterns in the source. What other algorithm could I use? I could just transform the identifiers to ‘x’s and leave the keywords alone. That would eliminate some ‘false positives’, patterns of duplication that we can’t really extract.

Clearly, the number of ways that we can transform the source when detecting duplication is endless: we can transform the source in any number of ways depending upon the type of duplication we’d like to highlight.

Whenever I'm this situation, I feel like I'm overwhelmed by choice. I feel like I’m making a choice, but I know that it can change, and more often than not that means I need another object.

In this case, a DuplicationDetector could use a LineTransformer class to do its work. Maybe we can have several different kinds of LineTransformers. We could have an ExactMatchTransformer that accepts a line and returns it with all of of its runs of whitespace converted to single spaces. And, we could have an IdentifierInvariantTransformer which takes a line and returns a copy of it that has all of its identifiers converted into 'x's.

Here's our DuplicationDetector with line transformation delegated to another class:

public class DuplicationDetector
{
    private LineTransformer transformer;

    public DuplicationDetector(LineTransformer transformer) {
        this.transformer = transformer;
    }

    protected String transformLine(Line source) {
        return transformer.transform(source);
    }

    ...

}

If we are aware of the choices that we make as we make them, we can decide whether they are choices that can change or not. If they are, it’s worth thinking about creating objects that embody them.

If you've encountered the Strategy Pattern before, what I've been writing about is bound to sound a bit similar. Strategy is a design pattern which describes how to use objects to encode algorithms and make them swappable at run-time. If you have two ways of doing something you create an object for each of those ways, and make sure that the appropriate one is used at the appropriate time.

To me, it isn't much of a stretch to say that all classes are really strategies in a way. Whenever we make a reference refer to an object, we are making a choice, and it is a choice that we can change by making the reference refer to another object.. provided we've made objects that embody meaningful choices.

---

!commentForm