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 primitives.
For example lets say you have the following code in your application:
The problem comes into play when you go to construct a CoffeeShop object. It can be awkward and require you to recall the correct order of parameters:
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:
But there is a simpler and more elegant solution: Tiny Types.
Refactoring our initial example with Tiny Types:
Now our CoffeeShop is refactored to use the Name object:
This pattern provides a number of benefits:
- Strong Typing - It is now easier to refactor this code down the road (ever tried to ‘Find Usages’ on a String?)
- Context - These types now have context so they can handle things such as validation or other domain specific actions internally.
- 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.