I find it useful to think about this rule and the following three rules as somewhat of a unit, since the refactorings needed to implement them cut across them, and are also part of a feedback loop. Here are the rules:

• Keep All Entitites Small.
• Maximum 2 instance variables per class.
• Use first-class collections.
• Don’t use any getters/setters/properties.

Here are the refactorings:

• Remove Fields.
• Encapsulate Collections.

• Split Classes.
• Minimize Visibility.

Removing fields and making first class collections are all about encapsulation. One way to go about this is to try to make all fields private (i.e. no getters/setters), then move functionality and fields around, and relax visibility of the fields, until you have a working system again. This will automagically make separate classes. But, they might be too big.

Breaking up classes makes packages bigger. So, you need to cluster the new quiver O classes into packages. This is an optimization problem: You need to minimize visibility (of the classes themselves, as well as the methods) and also minimize the number of packages, so that only those classes which need to be in the same package with their friends, are. During this process, you might want to increase visibility and reintroduce getters/setters so that you can make your packages “work”. Then it’s back to the previous paragraph.

What I did

First, I tried to repackage.

Then, I did an exercise to minimize instance variables.

Then, I worked on refactoring the domain model so that collections had more functionality (First Class Collections), and the object model was more granular (Splitting Classes).

Then, I worked on repackaging again, and finally got rid of the getter/setters (Rule #9). This was trivial, especially since I cheated – I couldn’t get rid of the intValue() method on WrappedInteger! In fact, the method is central to the entire application! This doesn’t surprise me – it’s the type of cross-cutting getter that wrapping primitives makes necessary …

To split classes, I started by looking for “responsibility” and making each class do just one thing. For example, my Solver used a chart to memoize the sub-solutions as it recursively solved the large problem. I removed the chart and put it in its own class, then gave the class more functionality so that the solver had to have the bare minimum number of lines to do its memoization.

My end state has no getters, EXCEPT the “intValue()” on the WrappedInteger class. It does, however, have members of a package which use the package-local visibility of another class’s field to peek at it. In fact, the collections package is the largest one in my solution (!), with nine (yes, 9) classes. Not all are collections, but the domain model really revolves around collections. and so its name is a historical artifact. In fact, hell, I should just rename the package “model” or something. In this way it’d exclude the “primitives” package – but hmm, maybe I’ll make that a sub-package of domain. Hold on …. OK, done. That took all of 3 minutes.

About those Classy Containers

In the process of making first-class containers, I found it useful to use two levels of implementation, and sometimes three:

1. Make a minimal collection which just uses the Java collection framework to do what it needs (e.g. is it a list, or a map? It is sorted?) This is just instantiating a generic collection and putting non-domain-specific functionality on it.
2. Wrap the base collection with additional concerns. Usually, you want to do this by containing the base class rather than extending it. By doing this you hide all of the stuff you don’t really care about for your domain collection.
3. Sometimes the class becomes large enough and with enough extra, domain-specific functionality, that you can extend the secondary class, and make the top-level class the only public one.

A First Class Collection example

The domain model revolving around sets of coins goes like this (TODO: Produce a class diagram):

A CoinSet has a bunch of CoinRolls. A CoinRoll is a roll of a single denomination (like that roll of quarters you have on your beside table at home), whereas a CoinSet has more than one denomination. The implementation of CoinRoll has 3 levels:

• CoinRollSet – This is just an extension of a Java collection template instantiation.
• CoinRollCollectionBase – This contains a CoinRollSet, implements Iterable, and adds the stuff I’ll need for a proper object: toString, equals, hashCode, all of that. It’s still very much a low-level class.
• CoinRollCollection – This is the only public class in this 3-level “hierarchy”, and has a couple domain-specific methods (containsDenomination and totalCoinCount). It also contains deepCopy, which while not domain-specific, is a good place for it since it’s like a constructor.

Another First Class Collection (but, not quite as classy)

In the case of the memoization chart mentioned above (called SolutionChart, strangely enough), the basic class can store a set of solutions for each Money amount being solved for. I used a HashMap as the basic storage, and contained it in a class with the functionality to create a solution from a CoinSet; and to decide whether the CoinSet was empty. Since I needed so little of the HashMap functionality, I didn’t even bother to extend it into its own class.

It felt good. I kind of felt like I had just taken a nice hot shower after swimming in the Charles.

Not only did I get rid of abbreviations, I also renamed after thinking a bit about what a meaningful name would be, and I also tried to standardize naming.

So, whereas MinNumCoinsSolver became MinimumCoinCountSolver (abbrvs),
many instances of “greedySolution” became “highestFirstSolution” (because the class that produced them had always been named HighestFirstSolver).

I also split the “Helpers” class into several different types of helpers: Again, this was not merely watching out for abbreviations, but also paying attention to reasonable naming and even packaging (a prelude to Rule #6)

There were also some egregious offenders which went beyond the simple intValue() gaff. A nice examples below:

BEFORE:

    while( index >= 0 && ordered.get(index).intValue() >
        total.intValue() - ret.sum().intValue() ) {

AFTER:

    while( index >= 0 &&
        greaterThan( ordered.get( index ), maxAddable) ) {

Aside from that there were some required uses of temporary variables (below). Precious few “real” encapsulation examples, so I seem to not have been a huge offender on Demeter’s law. Not this time around at least …

BEFORE:

return this.getClass().getSimpleName() + "<" +
     Helpers.stringJoin( getCoinSets(), Joiner.COMMA ) + ">";

AFTER:

final String className = klass.getSimpleName();
return className + "<" +
     Helpers.stringJoin( getCoinSets(), COMMA ) + ">";

In the Friendly Coins problem, it’s fairly clear there are at least three distinct flavors of numbers (all integers, by the way):

• A coin has a Denomination (e.g., a nickel has a denomination of 5 cents).
• When you are making change, you will then have a certain number of each Denomination. I decided to call this flavor of number a Cardinality.
• Finally, there is the number which arises by combining a bunch of Denominations into a handful of change (which we hope is Friendly, of course). I decided to call this Money, because that’s what it is, after all.

Since we are dealing with small objects, I used the Instance Singleton pattern to make sure each Denomination and Cardinality only ever had one instance in memory (I decided NOT to do this for Money, since Money is only ever persisted in memory about once per value in the solution, and Money, unlike the others, is mutable – and I didn’t even want to think about implementing copy-on-write).

Just a small taste:

BEFORE:

public static CoinSet createCoinSet(Integer... denominations) {
    return new CoinSet( denominations );
}
...
int sum = 0;
...
private void incrementDenomination( int denomination ) {
    int card = getCardinality( denomination );
    denominations.put( denomination, 1 + card );
    sum += denomination;
}

AFTER:

public static CoinSet createCoinSet(Denomination... denominations) {
    return new CoinSet( denominations ) ;
}
...
private Money sum = new Money();
...
private void incrementDenomination( Denomination denomination ) {
    Cardinality card = getCardinality( denomination );
    setCardinality( denomination, Cardinality.getInstance( card.intValue() + 1 ));
    sum.addCoin( denomination );
}

One of the choices I made when encapsulating the ints: since Integer cannot be extended, I could either add methods to my own spanky new WrappedInteger base class, or provide static helper methods. If one writes helper methods, one immediately gets into the game of exposing the internal value (oops, there’s a line of code or a dot or whatever); manipulating it (a call to a helper); then possibly re-encapsulating it. So, I gave WrappedInteger the needed comparison and plus/minus methods.

So, I recompile, and LOOK: I get warnings to the effect that I am comparing nonconvertible classes when I do this:

if( total.equals( denomination ) )

… Happily, this is exactly what I want to do – if the total change to give is equal to the denomination – then it’s a single coin. But in general, comparing denominations and Money would seem to be a no-no (since Denominations aren’t really money; they’re just the abstract concept of the possibility of representing a Money. You need a Denomination and a Cardinality to make Money). So to avoid the warning, I do this:

 if( new WrappedInteger( total ).equals( denomination ) )

In fact, this is exactly what I want – normally, comparing apples to oranges is not good. In this case, all I needed to know was whether the apple weighed exactly the same. Or, was the same color. Or, something. You know what I mean.

In my case I’m not sure I’ve done things in a complete optimal way – I got rid of the messiness of helper methods, but have some warnings in the implementations, and try as I might, I simply cannot get my WrappedInteger implementation to not exceed the 50-line limit (!)

I’m sitting here wondering: If Java had automatic casting (as does, for example, Scala), or allowed me to extend Integer, then instead of implementing my own arithmetic and comparison methods, I’d just use the out-of-the-box stuff, and everyone would be happy. Boo Java. Or, boo on me, if there’s some simple thing I should have done but have missed. On the other hand, the exercise of designing my own general numeric classes and specializations was valuable in its own right …

Less Mundane stuff …

In addition to the numeric types, I played with the StringJoin helper method, introducing Joiners and Joinees.

BEFORE:

public static final String EMPTY_STRING = "";
...
public static String stringJoin( Collection objects, String joiner ) {
    StringBuilder builder = new StringBuilder();
    String useJoiner = EMPTY_STRING;
    for( Object o : objects ) {
        stringJoinAppend( o, useJoiner, builder );
        useJoiner = joiner;
    }
    return builder.toString();
}
private static void stringJoinAppend( Object o, String joiner,
        StringBuilder builder ) {
    builder.append( joiner );
    builder.append( (null == o) ? "null" : o.toString() );
}

AFTER:

public static final Joiner EMPTY_STRING = new Joiner("");
...
public static String stringJoin( Collection objects, Joiner joiner ) {
    StringBuilder builder = new StringBuilder();
    Joiner useJoiner = EMPTY_STRING;
    for( Object o : objects ) {
        stringJoinAppend( new Joinee(o), useJoiner, builder );
        useJoiner = joiner;
    }
    return builder.toString();
}
private static void stringJoinAppend( Joinee o, Joiner joiner,
        StringBuilder builder ) {
    builder.append( joiner );
    builder.append( o.toString() );
}

Aside from giving me a place to put the constant Joiner.COMMA (commonly used, of course), and the nicety of having the translation of the null value to the string "null" be in the Joinee class, I question the use/smell of this particular change, because in the end, the implementation is twice the length of its original (I didn't show you the Joiner and Joinee classes - they're rather mundane). Maybe there would be future methods that also use Joiner and Joinee, making it all worthwhile. On the other hand, its usage (as opposed to its implementation) is virtually identical to before the change; the only thing you have to do is send the stringJoin method a Joiner rather than a plain String (the Collection sent to it is automatically converted itemwise into Joinees).

BEFORE:

public int getCardinality( int denomination ) {
    if( containsDenomination( denomination ) ) {
        return denominations.get( denomination );
    } else {
        return 0;
    }
}

AFTER:

public int getCardinality( int denomination ) {
    if( containsDenomination( denomination ) ) {
        return denominations.get( denomination );
    }
    return 0;
}

This of course violates the prescription “Only have one exit point for a method” – and also increases the cyclomatic complexity. But, these are both Allowed for this exercise. Besides, I must say I’d choose the AFTER aver the BEFORE any day.

It’s not always that simple:

BEFORE:

private void accumulateTotal(CoinSet coinSet) {
    if( 0 == total ) {
        total = coinSet.sum();
    } else if( coinSet.sum() != total ) {
        throw new IllegalStateException( "All coinSets must have the same sum" );
    }
}

AFTER:

private void accumulateTotal(CoinSet coinSet) {
    if( 0 == total ) {
        total = coinSet.sum();
        return;
    }
    if( coinSet.sum() != total ) {
        throw new IllegalStateException( "All coinSets must have the same sum" );
    }
}

I like the BEFORE in this case. Assuming that is that I like the throwing of the exception – which, no, I don’t. Never mind, this all gets refactored later on anyhow.

Much more gratifying than either of the above is the chance to get rid of plain bad smelling code, by reducing the number of variables, curlies, and dropping the else:

BEFORE:

public static String stringJoin( Collection objects, String joiner ) {
    StringBuilder builder = new StringBuilder();
    boolean first = true;
    for( Object o : objects ) {
        first = stringJoinAppend( o, joiner, builder, first );
    }
    return builder.toString();
}	

private static boolean stringJoinAppend( Object o, String joiner,
        StringBuilder builder, boolean first ) {
    if( ! first ) {
        builder.append( joiner );
    } else {
        first = false;
    }
    builder.append( (null == o) ? "null" : o.toString() );
    return first;
}

AFTER:

public static String stringJoin( Collection objects, String joiner ) {
    StringBuilder builder = new StringBuilder();
    String useJoiner = "";
    for( Object o : objects ) {
        stringJoinAppend( o, useJoiner, builder );
        useJoiner = joiner;
    }
    return builder.toString();
}

private static void stringJoinAppend( Object o, String joiner,
        StringBuilder builder ) {
    builder.append( joiner );
    builder.append( (null == o) ? "null" : o.toString() );
}

I think this will be interesting for at least a couple reasons:

• It’ll give me a chance to see which of the Nine I tend to diverge from the most.
• I’ll be able to do a before/after measurement on a few code metrics (for example, complexity and cohesion).

The first refactor I applied was “Use only one level of indentation per method”.

Micro-state sharing

The bulk of the changes involved moving loops into their own methods.

I noticed a two variants of a micro-pattern. First, let’s look at a stringJoin (yes, this is available elsewhere — but I decided not to use any non-core libraries, and even to not use core implementations if writing the code might exercise some of the Nine Rules).

BEFORE:

public static String stringJoin( Collection objects, String joiner ) {
    StringBuilder builder = new StringBuilder();
    boolean first = true;
    for( Object o : objects ) {
        if( ! first ) {
            builder.append( joiner );
        } else {
            first = false;
        }
        builder.append( (null == o) ? "null" : o.toString() );
    }
    return builder.toString();
}

AFTER:

public static String stringJoin( Collection objects, String joiner ) {
    StringBuilder builder = new StringBuilder();
    String useJoiner = "";
    for( Object o : objects ) {
        first = stringJoinAppend( o, useJoiner, builder );
        useJoiner = joiner;
    }
    return builder.toString();
}

private static boolean stringJoinAppend( Object o, String joiner, StringBuilder builder ) {
    builder.append( joiner );
    builder.append( (null == o) ? "null" : o.toString() );
}

Now, let’s look at a method which find a minimal value (yes, yes, here I am reimplementing the wheel – in the interest of calisthenics).

BEFORE:

private CoinSet findMin(Collection coinSets) {
     CoinSet theLeast = null;
     for( CoinSet coinSet : coinSets ) {
         if( null == theLeast || coinSet.getNumCoins() < theLeast.getNumCoins() ) {
             theLeast = coinSet;
         }
     }
     return theLeast;
 }

AFTER:

private CoinSet findMin(Collection coinSets) {
     CoinSet theLeast = null;
     for( CoinSet coinSet : coinSets ) {
         theLeast = isItLess( theLeast, coinSet );
     }
     return theLeast;
 }

 private CoinSet isItLess(CoinSet theLeast, CoinSet coinSet) {
     if( null == theLeast || coinSet.getNumCoins() < theLeast.getNumCoins() ) {
         theLeast = coinSet;
     }
     return theLeast;
 }

I am claiming this is a “micropattern” characterized by the fact that there is state associated with the loop, and the state needs to be managed by coordination between the caller and callee methods. In the case of stringJoin, the state is whether or not to append the spearator to the string. In the case of findMin (which actually has a more descriptive name in the real source), it’s what the minimal value found so far is.

How the state is managed between caller and -ee differs in the two examples. In the stringJoin case, the state is independent of the called method (i.e., the caller maintains state). In the findMin case, the called method is responsible for maintaining the correct state. It would be possible to re-implement either method so that the responsibility is flipped. It’s just that the way I implemented both of them smelled right to me on the day I did it. It is worth noting that in the stringJoin, I have a redundant assignment (the assignment need only be done on the first pass through the loop). However, I liked getting rid of the “if” test that would be necessary. On the other hand, finding the minimal value does need a conditional, so putting the “if” in the callee works nicely.

Try / Catch – Problematic

Tricky to eliminate extra indentation were the try/catches – in this case, I took the requirement to be that there be 0 levels if indent inside the try/catch.  These are almost like a loop-removal, but seem to me to be more “woven” into the rest of the method (because of dependencies on variable).  This particular refactor smelled a little bad to me. I’d even say that try/catches might by their very nature introduce extra complexity that requires extra effort in implementation.

Strategy Pattern / Anonymous Methods / Yield / Micro-IOP

Also interesting, was one instance of a “collect” pattern (as in, the Ruby language “collect” method, which in other languages might be called “map”):

BEFORE:

@Override public String toString() {
      String ret = this.getClass().getSimpleName() + "<";
      boolean first = true;
      for( int k : denominations.keySet() ) {
          if( ! first ) {
              ret += ",";
          } else {
              first = false;
          }
          ret += k;
          ret += "'s:";
          ret += denominations.get( k );
      }
      return ret + ">";
      items.add( item );
  }

I tried to get tricky and introduce a first-class “foreach” in order to use the already-refactored stringJoin. The idea is that the difference is what gets executed INSIDE the foreach – so, since Java in its Old Skool way doesn’t yet have real anonymous functions, I tried to make one.

AFTER:

public String toString() {
      final Collection