Better Java

http://blog.seancassidy.me/better-java.html

by bqe • 12 years ago

17 4 12 years ago

blog.seancassidy.me

skybrian• 12 years ago

I disagree on Util classes. They're fine so long as they're as well-tested as regular code and divided up by the libraries they depend on. (Put all your IO utils in one place, all your database utils in another, and so on.) Guava has lots of nice utility methods for Maps, Lists, streams, and so on.

Fishkins2• 12 years ago

I don't necessarily see a problem with Util classes, either. He didn't really say why they're bad. Actually, I guess he didn't describe why we should do most of the things he recommended, but I agree with most of the other advice.

Fishkins2• 12 years ago

Mostly good advice. I'm surprised he talked about Joda Time and Java 8 without mentioning Joda Time is (essentially) included in Java 8.

ajanuary• 12 years ago

Using public fields could be a bad idea if on classes that are exposed to third parties because it prevents you from changing it to a calculated field while keeping compatibility. However, this is going to be a very small number of classes.

Personally I have a small Tuple class I use for small immutable data holder objects that automatically implements hashCode and equals:

    public final class DataHolder extends Tuple2<String, Integer> {
        public DataHolder(String data, Integer value) {
            super(data, value);
        }

        public String data() { return get(0); }
        public Integer value() { return get(1); }
    }

Obviously there's a bunch of limitations: you can't use primitive data types, and it doesn't really scale past 3 or 4 fields, and can get hairy when you have multiple fields of the same type. It's easy to graduate once you get to that point though.

Better Java

Related Stories