Refactoring

As an increasingly big fan of refactoring and all that comes along with it, I still appreciated a point made by John Reynolds.

It is relatively hard to inherit Java because you have to comprehend the abstraction. It is like trying to explain a concept by using an analogy. If your listener shares your cultural background, an analogy can open the doors to greater insight. If your listener doesn't get the analogy, you may have slammed the doors to understanding shut. The wrong abstraction choices can destroy code maintainability.

To take the quote only slightly (hopefully) out of context: I find it an especially interesting point as I tend to work in environments where several of the Java developers are not really all that experienced with Java (converted COBOL developers, newbies, etc). Initially, my thinking was: The answer isn't dumbing down the code/design, the answer is educating the person. To an extent I still feel that way, but on the flip side of the coin: There has to be a point where a combination of YAGNI and a plain desire to be obvious can override the point where abstraction is really benefitting your project (near and long term).

I know that I've cursed and moaned about modifying some complicated piece of code only to find out later that I just didn't quite see where the original developer was going with their design: had I seen it in time, the mod would have been much easier.

I've been on the other side too. Wondering how this simple change could be taking someone two weeks and wandering over to find them re-inventing the wheel because they're missing the point.

Anyway, the quote above and a few other posts that I've read recently have me looking forward to tomorrow's MADJUG meeting.

I'm not sure how much Rob plans on splitting his time up, but I'm hoping there will be some discussion of:
1. How to refactor (patterns, tips, and techniques)
2. How to refactor (how to leverage the IDE)
3. How to refactor (how much is appropriate)