Yet another layer of indirection

I have spent a week heavy on the refactoring side. It’s been a while since I spent so much time on a “virgin” codebase, growing it test first. And I want to share with you, guys and girls, a piece of refactoring that ended up being pretty cool.

While developing the improvements for the Generate class of Testing.Commons I faced an API design challenge that I, at least, consider challenging.

It’s been a while since I gave my very exciting (at least for me ) talk about CQRS.

I think I said it before, but there are little things as challenging (for a developer) as showing your code publicly. Of course, there are few things as rewarding (for a developer) as showing your code publicly. It is always nerve-breaking: Will they understand it? Will they think is total crap? Will they be aware of all the trade-offs made?

Wow I cannot possible squeeze more acronyms into a title (God knows I will keep on trying :-p)

The other day I was having a look at what was new on CodePlex when I stumbled upon the sample code that accompanies the book .NET Domain-Driven Design with C#: Problem - Design – Solution.

LSP (or Liskov Substitution Principle) the L in SOLID has a somewhat abstract definition, but basically, as Uncle Bob states it, is:

But before drilling the progressive interface an introduction to the closure “ingredient” is needed.

I like some fluent interfaces. Not that I’d like everything API to be this way, but in some situations, it certainly helps due to its expressiveness. The only problem is that, if not created properly, it is difficult to choose the next method in the chain. For that purpose a different type of fluent interface, the so called progressive interfaces, was ideated. The difference is that with the later, the user of the interface will only have available those methods that can be chained for the given link. In other words, progressive interfaces are fluent interfaces that are easy to explore.

I have already written about the “principle of least surprise” applied to API design and how Microsoft’s .Net Framework developers themselves ignore their own recommendations.
I would not care less if their violations did not waste my time, but they do.

“Integration” is a very overloaded term (almost as much as “implement”) and I took advantage of it in my not-so-catchy title.

I was preparing some material for some training I gave to some of my co-workers when I realized how the usage of Dependency Injection and getting comfortable with IoC containers has been assimilated into my standard way I develop enterprise software.

I just hope no one denies the great value of following these principles.

I am a great believer that by simply observing them every now and then, the quality of the code you create can improve by several orders of magnitude.