I Built His Cage

Announcer: Now for quick hits and commentary on software development topics from around the web, the EIP web-ring brings you the stigmatized spawn of a refactory, MoffDub, and Helltime!

Alright! Yip yip yip yahoo, we are back at Full Throttle Operational Status here at the EIP web-ring. Expect an update on the Ropes H’yung on Wednesday.

• JavaBlogging chronicles an interesting tale on choosing between Comparable vs. Comparator. In short, the design decision to have an object implement Comparable led to problems later when that object was used in a context when duplicates were allowed. This happened because Comparable nudges one to also implement equals() and hashCode(), and originally equals() was implemented to disallow duplicates. The author concludes that Comparator is a safer alternative.

  I disagree. The problem was overriding equals() to start with. If you know your list of objects can contain multiples, don’t override equals(), in the case of Value Objects, and do override equals() (correctly, based on identity and not attributes) in the case of Entities. To be totally safe, though, I’d consider adding fabricated non-persistent identity to such Value Objects and override equals() anyway. I’m kind of paranoid.

• The Agile DZone features an essay by Torbjorn Gannholm evangelizing the value of clear code. He joins an echo, that includes me, in saying that if you find yourself commenting your code, it is time to refactor. I like to call this refactoring “Extract Comment”.

  I get blue in the face telling it to people, but I suffered the penalties of vague code mere moments ago. A co-worker asked me to look at an existing issue whereby a local variable was shadowing a member variable in a class because they shared the same name. Here, folks, is a situation where the variable name subtracted hours of work, and thus thousands of dollars, from our company. How many innocent green Washingtons must die before we learn this lesson?

• Samir Bellouti from Another Brick In The Wall has an excellent and exhaustive post on proper exception handling. It is really worth a read because it is quite good. The biggest point you have to take away from his post, though, is to only catch the exceptions you can actually handle. If you can’t do anything about it other than log it, step aside.

  I will say that Samir brings up an intriguing It Depends^TM question: what situations are truly exceptional? In other words, how do you avoid writing your control flow by throwing and catching exceptions? I have a feeling that if I can ever get Hydrocon off the ground again, you will be seeing a post on that very topic.

Announcer: You’re reading the EIP web-ring.