I have not been in the java world for long, but I have noticed some strange behaviours that I cannot - and probably won't - cope with. For the purpose of this post, let's just stick to a specific problem. If you see the following example, you go wild about it, because you just don't do this. Period.

But in most java codebases you can find the following implementation:

I hope I will not bust a big myth to you, but the 2 examples are identicle. The only difference is that the latter looks better.

So what's the fuss anyway? I'll tell you in a second. Imagine that you are a consumer of a Book instance and you have to read the title, author and the price of a book.

Since you can never be sure that the title of the book is set, you need to add a null check to every place where you try to read from the object. You can argue that the programmer should be disciplined enough to set the fields at every stage, but we are all just humans who make mistakes. But why would we deliberately make our lives error prone?

Mutable object

With our current Book implementation, we created a mutable object. Why is that? Because you can alter the state of the book instance at any point of it's lifetime. It is born, it lives across your system then it dies. But while it lives, you can call the setters and change the title, the author and the price. Although the price might change over time, the title and author are unlikely to.

Why is this bad?

As a programmer, you have to remember to set up the object correctly. You have to validate the data before you use it at every point. Unless you perfectly know the whole of your system, you'll never know what your Book consumer method will receive. Altering the state runtime may cause problems in other parts of the system which only work with a specific state.

The common solution to this problem is to use immutable Value Objects.

In object-oriented and functional programming, an immutable object is an object whose state cannot be modified after it is created

http://en.wikipedia.org/wiki/Immutable_object

With this implementation whenever a Book is created, it is created with a title, author and a price which can be accessed from any consumer. These values will stay with the book for it's whole lifetime, because there is no way to change them. I tend to trim the word "get" from the getters with value objects, it makes more sense to me to call a book.title(), but that's only one way to do it. The point is to eliminate all the unnecessary setters and put the assignments of required fields up to the constructor.

 

We're not superheroes I was reading bits of Coders at work, a book of interviews to famous programmers. I didn't like it very much: here's why. The first thing I noticed is that many questions are biographical. I do not care about knowing if Ken Thompson, which built Unix, worked on a PDP-10 or a PDP-11 or a PDP-7. By the way, I do not even know how those things look like: I was born in 1988. Besides that, this kind of books tells you how to live like a superhero coder, but most of us just aren't (me too). Thompson could work out the design of software in his mind for a month before starting coding, I can't (or I can waste less time by writing something in code). Knuth could design and code LaTeX in pencil and write for six months before do any testing. I can't (or I can, but I would be much more efficient with a quick feedback loop like Test-Driven Development's one.) Zawinski could pick up rolls of duct tape and make Netscape work in six months (picking up also a lot of technical debt and vanishing from the market in the following years). I prefer working software over comprehensive documentation but not over sustainable development. So we're not superheroes: test suites, source control, Continuos Integration are our bat-gadgets which enable us to deliver software while working for a living and not living for work, like Ken Thompson and his 28-hour days or Bill Gates and his nights at school programming. Let the people with the superpowers shoot webs all night long, while we go back to Wayne Manor and throw a party. At least Batman hasn't a day job: poor's Peter Parker must live a miserable life. Published by Giorgio via We're not superheroes - Invisible to the eye.

In other words: If you find a bug, you MUST do the following steps immediately:

• Record reproduction steps with selenium - or such - (for web projects)
• Write a note about the encounter
• Attach the selense file and the note to a bugreport in an issue tracker (you have one do you?)
• Try out other possibilities to recall the bug (or similar faults)

If you follow the steps above, it's almost good. Just don't forget to fix them before implementing any new features.