Small case in favor of setter injection

In general setter injection is frowned upon. The main reason is mostly that an object should have all its dependencies at the creation time. That is very reasonable, but I find it a tad on the paranoid side. Or better put, I have been using setter injection only and have not found any problem ever. Furthermore, by having setter injection my objects and test code has remained cleaner than the alternative options.

Here are the rules

• Depend only on interfaces
• Don't use new
• Don't define constructors in the class

Depending always on interfaces sounds extremist. But it happens naturally if a system is developed outside-in mocking the dependencies. The principal advantage of mocking is increased focus at the time of writing the code, the decoupledness is a side effect. Another side effect is that the interface becomes the public interface of the class.

Therefore making things public in the class doesn't break encapsulation. I do confess that having more public and virtual elements in the class obscures the understanding of what the class offers. But the interface is right there and it's easy to see what the class is exposing to others thru it.

Depending only on interfaces needs to be accompanied by forbidding the use of new. If an object has a dependency say "Command ToSave;" and does "ToSave = new SaveCommand();" to create it. The class would have a dependency on both the interface Command and the class SaveCommand.

Once new is forbidden there are two ways to create a class, either by having a factory object or by using a DI framework. Both approaches would lead to the decision of setter injection vs constructor injection. I chose setter because the class ends up cleaner that way by not needing constructor logic.

There's no way of generating an object on an unstable state because the dependencies are either injected by a framework or they had to be passed as args to the factory method. There's a backdoor to the object via new but it is simply forbidden and conveniently available to the test code.

The test code becomes simpler because we need to mock only the dependencies involved on a particular behavior. It is a smell to have multiple dependencies and only some of them needed at a given time but it happens. Even if it's only at some stage before the object is refactored into a better design.

The Rules of Coolban

1. Do not talk about Kanban

2. Do not talk about Coolban

3. Every rule can and should be challenged

4. A story is ready to Code when the acceptance tests are done

5. A story is ready to Test when the acceptance tests are green on QA environments

6. A story is in Build after being preapproved

7. A story is Done after being demoed on an integration environment

8. Every story has a sponsor, if you are the sponsor, you should pave the story's way to Done

The Passionate Programmer

The fact that I published this proves how valuable is "The Passionate Programmer" by Chad Fowler. I am applying his advice of "Let your voice be heard" from the chapter "Marketing... Not just for suits". I already do roughly 80% of the things recommended in the book to guide you in a path of a great career. But what makes it unique is the fact that I agree with 100% of what it's saying and it pushes me to do some of that 20% I keep chickening out of doing.

If you already have a great career you would read this book at a Dreyfus  level of Expert. In such case I can't really tell how the expert to expert transfer of knowledge goes. You might enjoy the anecdotes, especially when they lead to metaphors back and forth between music and programming. It helped me do retrospectives on misbehaviors like in "Learn to love maintenance", so you might map errors in early years like when I desperately wanted to leave my team in 2008 to escape from legacy code.

The book is the second edition of "My job went to India: 52 Ways to save your job" and it was refactored to read more like 52 advices to make your software development career shine. It still has a lot of references to India since the author lived and worked there. For instance, the warning about "The South Indian monkey trap" is an eastern version of the boiling frog from "The Pragmatic Programmer". I do think however that it's more cruel because they actually do that to monkeys.

The book closes with the advice to "Have Fun". "Software development is both challenging and rewarding. It's creative like an art-form, but (unlike art) it provides concrete, measurable value". If you've chosen to become a software developer this book reassures you why you should feel lucky and offers advice on how to steer you career.

I didn't choose to be a software developer, I am a natural born programmer. I am not a geek, I just happen to have natural inclination to think in terms of programmable algorithms. That is what I enjoy the most and it feels as creative and cool as to be a rock n' roll guitar player. This book is about how to make it to the big gigs and perform at the highest level in your profession. To become a rock start doing what you love, programming.