Tiny Types

December 9, 2014

I was recently introduced to a ‘mini-pattern’ called ‘Tiny Types’ by a co-worker. It boils down to creating types where you would normally use primatives.

For example lets say you have the following code in your application:

public class CoffeeShop {
  String name;
  String address;
  String state;
  int zip;

  public CoffeeShop(String name, String address, String state, int zip) {
    // initialize
  }
}

The problem comes into play when you go to construct a CoffeeShop object. It can be awkard and require you to recall the correct order of parameters:

CoffeeShop cs = new CoffeeShop("Is it address here?", "Or is it name?", "Blue?", 55555);

You get the point. Yes, we do have modern IDEs such as Eclipse or IntelliJ that can help you remember the order of parameters. And yes, you could use the Builder Pattern:

public class CoffeeShopBuilder {
  String name;
  String address;
 
  // builder setup

  public CoffeeShopBuilder withName(String name) {
    this.name = name;
    return this;
  }

  // ...and so on

  public CoffeeShop build() {
    // create the coffee shop here
  }
}

But there is a simpler and more elegant solution: Tiny Types.

Refactoring our initial example with Tiny Types:

public class Name {
  String name;

  public Name(String name) {
    this.name = name;
  }

  // other actions you might want to do on a name such as validate(), upperCase(), abbreviate().. etc.
}

Now our CoffeeShop is refactored to use the Name object:

public class CoffeeShop {
  Name name;

  public CoffeeShop(Name name, Address address, ) {
    this.name = name;
    // ...and so on
  }
}

This pattern provides a number of benefits:

  1. Strong Typing - It is now easier to refactor this code down the road (ever tried to ‘Find Usages’ on a String?)
  2. Context - These types now have context so they can handle things such as validation or other domain specific actions internally.
  3. Type Conversion - No longer do you need to do String.parse() when you need the zipcode as a String. Instead you can provide the asString() method on the Zip class itself.

Now I know some people may see this as over-complicating things and may shout ‘What about class explosion?!’. All valid points and I too felt this way when I first learned of this ‘mini-pattern’. However, after refactoring an existing codebase where we had to convert between String, long and int representations of an ‘Id’ object.. this approach was a lifesaver and helped reduce the number of programmer errors in the long run.

Note: This is definitely not an original idea. I had just never come across this pattern before and figured that others may benefit from it as well.

There are multiple blog posts describing this practice such as:

Give ‘Tiny Types’ a try in your next project or refactoring.. you may find that you actually like them.

Let me know what you think about this approach in the comments.

Did you find this content helpful?


Let me send you more stuff like this! Unsubscribe at any time. No spam ever. Period.


Subscribe to MarkPhelps.me

* indicates required

Discussion, links, and tweets

Mark Phelps

I'm a Software Engineer in Durham, NC. I mostly write about Go, Ruby, and some Java from time to time.