I wanna be a Craftsman. Thoughts about software engineering. by Roy Tsabari

The damned 'init' method

You probably saw this pattern many times before:

class MyClass {
 public init () {
 ...
 }
 
 public execute () {
 }
}

where the ‘init’ method prepares the object and do things like: loading configuration, initializing internal objects, etc. and the method ‘execute’ do the actual work.

Why is it bad?

Your client (who is using your class) can easily use this class in a way that will broke it. What will happen is he’ll create the instance and run the ‘execute’ method with calling the ‘init’ method before?

Like every piece of code we write, this class has a public API. A good API should direct the user to use it properly, in other words - do what can be done to prevent misuse. The critical information about the right way of doing things inside this class should be kept there as well.

So what is the right way? Well, all the actions that are related to creating the object and the things he need to do it’s job - should be be in the constructor. All the actions that are related to the ‘execute’ method, should be in it.

Finding the right way I can think of situations where the pattern above is a must-have.Still, in most cases it is bad to use it and you can find other solutions that will make your API more solid. For example, in C++ you can’t call a ctor from other ctor so instead of creating many ctors with different signatures you will be tempted to create a set on ‘init’ methods. One solution to this problem is creating a set on private ‘init’ methods and call it from to ctros. (thanks to @danprinz for this example)

Remove the 'i' from your interfaces

_config.yml

Let’s say I’m creating two classes - A and B, when A is using B.

Because I don’t want A to be coupled to B, I’am injecting an interface that B implements.

Until today, even if I had only one implementation for this interface, I created an interface called IB, implement it in B and inject it to A.

The idea of creating an interface just to allow me to change the implementation of B in the future always felt like violation of YAGNI.

Well, yesterday I reached the “Interfaces and implementations” section in Clean Code of Uncle Bob.

He recommends to prevent from adding an I to interface name because the client (who uses the implementation) shouldn’t know that he’s getting an interface:

I prefer to leave interfaces unadorned. The preceding I, so common in today’s legacy wads, is a distraction at best and too much information at worst. I don’t want my users knowing that I’m handing them an interface…. So if I must encode either the interface or the implementation, I choose the implementation.

Then I thought about the fact that there are many classes in Java libraries that don’t starts with an ‘I’ although they are an interfaces: CharSequence , Connection etc.

So, I have decided to stop adding the ‘I’ prefix to my interfaces. This way I can create a single implementation and extract an interface in the future if I’ll need it.