Tiny Types

Kerry — Sun, 15 Apr 2007 14:14:00 +0100

I consider it playing to the strengths of a statically typed language.

I like this pattern, and have used it once on a large Java project. Generally I prefer dynamic languages, Smalltalk and Ruby etc, but if you have types why not use them effectively.

Blaine Buxton puts it in terms I like:

Tiny objects make unit testing easier, aid in reuse, stop duplication dead, provide for better messages when things do break, puts functionality closer to where it is used, and I could go on all night.

I don’t necessarily use this all the time, I find a lot of developers reject the idea because of the number of Types you end up with. If I’m working on something of mine, or from scratch then I’ll use this approach, otherwise I tend to stick to the style of the original author.

One thing I’m not sure about is an example Darren wrote:

It’s much harder to accidentally pass dollars into a method that was expecting pounds sterling (but actually took a double so it could have been anything).

Money is money is money, would some methods really only take Sterling and not Dollars? Ever? Maybe this was a passing comment or maybe I don’t get this particular example.

This is a good technique to learn and I’d encourage anybody who hasn’t used it to give it a go. Maybe you’ll like it or maybe not, at least you’ll know. One really good outcome that I find is behaviour finds itself in a Class where it belongs, not in some Manager/Helper class just because it’s the first place the behaviour is needed. Not only does this technique work for primitives, but it works equally well for collections, especially where you have some find/collect type methods.

ronin: Tiny Types

Tiny Types