A Sea of Blue: Spotting Abstraction with a Theme

The other week I inadvertently coined a new phrase. It may actually be two phrases and comes from our recent concentration on abstraction in our controllers and main calculation engines. I just thought they were one of the silly things I say to help turn programming concepts into easier to use language – much like we use design patterns to communicate intent when pairing or discussing architecture. I was encouraged to blog about it by my colleague Shaun, who thinks this might go global.

Phrase 1: “A Sea Of Blue”

This is what we see when we open up a controller or engine that has a number of service objects injected in the constructor. The name came from the fact that we work in C#, in visual studio and our theme colours interfaces in light blue. It is generally regarded as a good thing as the class in question will be more testable as the services you don’t need can be easily mocked. We can return specific messages from some services, verify that others are called in a specific way and provide a mock with no setup/verification to skip over unwanted behaviour.

We’ve found that sometimes the sea of blue means that you have a long parameter list. We usually combat this by defining DDD style aggregates for service objects with related behaviour and injecting an aggregate service instead – maybe these are more a lake of blue – or maybe I’m getting carried away.

Phrase 2: “Making a Bluey”

This one is probably less likely to catch on, especially as most people think of something completely different when you say “bluey”. In other words, extracting an interface, or Ctrl+Shift+R and “Extract Interface” if you want to be fancy. We’ve had discussion recently whether we sometimes do this too soon – do you need an abstraction unless you need two concrete implementations? I often argue that the second implementation you have is the mock implementation you use in tests. My colleague (Shaun again) blogged about the way we should mock roles rather than types and one of things we’ve discussed before is that you should understand why you use a tool like Moq by actually implementing a mock/stub of the class rather than using Moq. This makes it more obvious that you now have two versions of the abstraction in existence and therefore the previous argument no longer stands.

I like the concept of emergent design and the use of test driven design to define the api of a class. I think this extraction of an interface, so that it can be mocked effectively and used without worrying about the concrete implementation, is an effect of the tests driving the code. The resultant api is cleaner, the classes can be well tested and your code can follow the SOLID principles.

The Theme

I’ll get our very latest version of the theme available soon on the company blog but for now you can try the old version, which works well in Visual Studio 2008 but because of the open type font restrictions in WPF and therefore Visual Studio 2010 you can no longer use inconsolata and some of the colours need updating:

http://codeweavers.wordpress.com/2010/05/27/a-better-colour-scheme-for-visual-studio/

Our new theme includes updates for 2010 and resharper 5 too.