Functional DI and breaking language boundaries

Today I received a priceless lesson on design, testability, Ioc and the way the boundaries of the development language we know may shape our thinking. It all started with a post by Derick Bailey on design and testability which lit a lively and truly interesting discussion. Derick was basically asking why people tend to demonise TypeMock even though it bares strong similarities to ruby mocking frameworks which are usually hailed by the same people, giving an example of how we tend to abstract dependencies in c# through interfaces, like so:

 public class Foo
private doSomething;

public Foo(IDoSomething doSomething)
this.doSomething = doSomething;

public void Bar()

It appears that with TypeMock we don’t have to have this abstraction
if we wish to test the DoSomething method is being called inside Bar;
we can just new up our IDoSomething implementation. This lead to a
wave of comments from people saying that this abstraction isn’t there
just for enabling testability, but quite simply functions as a better code design (ie dependency injection).

However, the main difference between the two platform, as it was put by Joshua Flanagan and Scott Bellware lays in the fact that all classes in ruby are open hence support for testability is provided in ruby within the language itself.

I was thinking about this question, trying to find another way to express  DI in c#, whilst attempting to reduce the superfluous abstractions, when the usage of delegations came to my mind, and I offered this solution:

public class Foo


 Baz _baz;

 public Foo(Baz baz){

 _baz = baz;


 public void Bar()





public class Baz


 private Action _doSomething = () => Console.Write("doing something");

 //or throw NotImplemented...

 public Baz(){}

 public Baz (Action doSomething)


 _doSomething = doSomething;


 public void DoSomething(){




And this is exactly where I’ve learned the most valuable lesson- Scott Bellware kindly enough provided a better solution to mine, in which he simply took out the redundant and, well, superfluous abstraction that was the Baz class and put the Action delegate directly in Foo. As obvious and trivial as it may seem, with a bit of refactoring or even stopping myself and taking the time to reflect a bit more on my solution I would have arrived to the same conclusion- no brain surgery. However, what I could see is that I still came up first with this solution rather than the other one. Even if I would have thought of the other only a minute after, still my mind reacted in this knee-jerk manner and spat out first this way of doing things. Bellware described it better:

“With the advent of callable objects in C# (Action, Predicate, and friends), command patterns can also be implemented using callable objects. However, there are years of habit-forming class-oriented implementation of command patterns backed up in idiomatic C#, and often command patterns fall back to the class-oriented habit even though there are now callable object alternatives.”

My mind is driven by the way I’m used to think in the language I use each and every day (c#) and in order to be able to break these language boundaries I will need to learn a new language, at least to be able to have different perspectives on issues I face on daily basis as a developer.

This fascinating nytimes article discusses the way our mother tongue may shape our way of thinking. One of the most example the article brings is that of ‘geographical languages’, where directions are given only by geographical coordinates (north, south…). The concept of behind, infront etc’ do not exist. The side-effect of speaking such a language can be quite far reaching- when put in a complete strange and unknown environment, geo-language speakers may lose their sense of orientation completely.

Learning new languages can help us get a new perspective on how we see things, how we perceive our surrounding and how we understand our reality. Sounds like a pretty cool thing to me 🙂

Read more: On Design and Testability- Derick Bailey

Explore posts in the same categories: Software craftsmanship


You can comment below, or link to this permanent URL from your own site.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: