The Little Guy

I said at the end of my sort-of review of Effective Java that a few things bugged me while reading it, not about the book, but about Java itself. These aren’t totally well-formed in my head, so I’m going to try to write them down in an attempt to get them to make sense. This may or may not work. Stay with me here.

I’m going to flick through the book to refresh my memory of stuff, so my thoughts will roughly follow the same order as the book, if you want to follow along.

Ah, here we go. A recommendation from chapter 2 (and the first itemised piece of advice in the book).

Item 1: Consider static factory methods instead of constructors

The gist of this is that constructors have some drawbacks. To name a few: they don’t have descriptive names; they always create a new object, where you might want to reuse an existing one; and they’re forced to return an object of that class, where you might want to use a subclass. Wrapping it in a static factory method gives you control over these things, and by making the constructor private or protected you can make the factory method the primary way for an APIĀ user to get a new object.

So, good advice. But there’s a little guy in the back of my head (you know the guy) who starts whispering little subversive things at points like this. He’s always yammering on about something, so it’s usually easy to ignore him, and I wasn’t really listening to him when I was only up to chapter 2… but by the time I was halfway through the book he’d said sensible things enough times in a row that I sort of started paying attention. Anyway, here’s what he said here:

Shouldn’t a language feature called a constructor support the ways that someone might want to construct an object? Why are we being advised to work around it?

Now, look, there are plenty flaws in that argument – the advice is that you consider using it where appropriate, not that constructors are always bad; and nowhere is it written that a language feature has to be usable from anywhere in its raw form for it to be useful. So the little guy hasn’t scored any points yet.

But keep this in mind. Later on (if I stay interested enough in the topic to keep writing about it) we’ll come back to why the little guy’s point was deeper than I realised at the time.

Okay, moving on. The next Item is about using an intermediate builder object when there are a lot of constructor parameters, especially if some of them are optional. There’s a comment in this section that I want to quote because it sort of sums up what my poorly-structured rant is about, albeit bluntly, and from a slightly different direction.

The Builder pattern simulates named optional parameters as found in Ada and Python.

And, I’ll add, most Lisp dialects, C#, Scala and, of all things, Visual Basic. Oh, and recent versions of Fortran. (Cheers to Rosetta Code. Also: there areĀ recent versions of Fortran?) I’m not arguing with Bloch here – it’s good advice for writing Java – but if you have to write boilerplate to simulate what other languages give you for free, it might be a hint that the programmer is doing work that really lies in the bailiwick of the compiler.

I’ve clocked slightly more hours writing Java than Python, but the Python hours are more recent. Reading this made me think about closing the book and swearing allegiance to Python. (Apart from the performance problems and lack of type safety. Oh, and I wasn’t reading it with the intent of converting. I was just trying to stay up to date. Seriously. Guido, I’d never leave you.)

I’ll leave it there – only two Items into the book – but to give you an idea of where the rant is heading, here’s a short talk by Rob Pike about Go.

Leave a Comment