mike.mainguy

Warning: This is a preoptimization In my previous post about equals and hashcode I thought I'd point out how to redesign the class in question to make better use of performance. If you have a situation where you create groups of objects that are immutable, but you need to pass them around in hashsets and/or look things up, a way to increase performance is to change from something like the following: package blog.mainguy; import org.apache.commons.lang.builder.EqualsBuilder; import org.apache.commons.lang.builder.HashCodeBuilder; public class LookupEntity { private String name; public void setName(String name) { this.name = name; } public String getName() { return name; } @Override public boolean equals(Object other) { if (other != null && other instanceof LookupEntity) { return new EqualsBuilder().append(this.getName(), ((LookupEntity) other).getName()).isEquals(); } else { return ...

Pundits often refer to the notion that the most effective developers are 10 or more times as efficient as the least effective. I think this is probably an understatement, but I think the reason is often oversimplified. Many of the "more effective" developers seem like to pat themselves on the back and chalk it up to being smarter or some other nonsense. While arguably this is true, I think it is more that the most effective developers HATE doing the same thing twice. I think this is an important detail because computers are REALLY good at doing the EXACT same thing millions of times per second. People are not very good at this... in fact it's arguable that it is impossible to do the same thing exactly the same twice in a row. The truly effective developers are the ones who use computers to do the repeatable tasks and use their unique human curiosity and creativity to find new things for the computers to do. More importantly, the best software development shops r...

The setup HashCodeBuilder is a nice tool provided in apache commons to help building infamously difficult hashCode and equals methods in java classes that work properly. While I appreciate the tool, versions prior to 2.5 had a subtle api design flaw that is likely to bite you if you aren't careful. To illustrate how subtle the design flaw is, take a look at the following code: package blog.mainguy; import org.apache.commons.lang.builder.EqualsBuilder; import org.apache.commons.lang.builder.HashCodeBuilder; public class LookupEntity { private String name; public void setName(String name) { this.name = name; } public String getName() { return name; } @Override public boolean equals(Object other) { if (other != null && other instanceof LookupEntity) { return new EqualsBuilder().append(this.getName(), ((LookupEntity) other).getName()).isEquals(); } else { return false; } ...

Clean code is a book by Uncle Bob Martin that speaks to principles in software development that lead to high quality, legible software. This is a great book and every developer should read it once (or twice). The book outlines important tools and techniques, but these are not the end, they are a means. I've noticed a lot of folks treat clean code as the "secret sauce" that makes great software. Unfortunately, they take it a little too far and by being too focused on their secret sauce, they forget that it's worthless if the customer starves to death waiting for the secret sauce to be "perfect". At one point early in the book, Uncle Bob uses the metaphor of physicians and hand washing. In particular, he makes a point that it would be unrofessional and possibly illegal for physician to not wash his hands before surgery, even if the patient (the customer) asked for it. I like this metaphor and I think he makes ...