I have read on previous occasions that there are three stages to learning a new language, whether it is related to computers or human language.
The first is comprehending. You might need a book beside you, but basically during this stage you are getting to grips with the functionality of the language, learning how to translate any existing language you know into these new constructs. You can make the language work, but you are still mapping to some previous concepts you already have.
The second is understanding. You can make the language function and now you start to understand how to express yourself in the natural way of that language. You form constructs naturally and learn to appreciate good constructs, and criticise bad ones .
Finally you master a language. You begin to see the limitations of the language and start conceiving new constructs. Not only do you know many possible constructs, but you can generally pick the best one for each situation, manipulating how your language will be understood by others.
I don’t think I could reasonably claim mastery of Java, but I realised I was well on the road to it today, as I saw two complex constructs. One was an elegant and original solution that lacked finishing touches; and the second was a stupid exhibition of code machoism, certain to confuse functional users, and generally be a pain in the ass. The good example deserves a post of its own, but I can plant the bad one here 🙂
Just because you can declare a new, anonymous inner class in a method call does not mean you should. I mean, maybe there is a practical use for this, but I’ve just never found it. As far as I can see:
- It makes your code a complete bitch to read. Classes in classes, sure. Classes in methods, maybe, if you really have to. Classes in methods calls though…
- It’s impossible for version control. OK, maybe Mercurial or Git could cope, but Clearcase and friends haven’t a hope
- Eclipse chokes. The correction works OK, but the search doesn’t find these classes.
- You end up writing it again and again. Write-once code occurs less often than we imagine, maybe aside from request/response type classes. Many candidates for small classes get reused frequently, so writing them over and over again isn’t efficient.
Anyway, I spent an hour today, writing some guy’s method-call-classes because someone updated an interface they implement, eclipse didn’t find, and version control couldn’t cope.
It’s ten times nicer to put them in a lovely little class file of their own, because frankly, little class files are the best ones. (Unless you create 50,000 of them.)