Excellent. Another of my co-workers has caught the RSS bug. We chatted a bit about my experience in Y! Finance to help prepare him for the, uhm, "organizational challenges" he may face.
I hope it works out. I'm always looking for good airfares back to Ohio and points East.
Success! I understand a bit of the object/interface model I'm working with--at least enough to add some functionality and not have it blow up. It compiles and runs. I've sucessfully extended my first real Java code in a meaningful way.
I got a TrackBack ping that lead me to K's article about my and Java which I thought was interesting. (K is not to be confused with Kasia who has been called "K" on some occasions.)
Apparently the transition I'm going thru is expected--or at least not unusual. That's makes me feel a bit less dumb when I'm struggling with this stuff. The other reassuring experience is sitting down with the code architect and finding that his design and implementation now stumps him to a degree too--at least in a few places.
K recommends that I look at Eclipse (again) as an editor that will help me out. I may have to do that. A fair number of folks have suggested it.
The next part is what has me wondering out loud...
I'll venture to give yet another advice. When getting to design with Java, know your Anti Patterns. Patterns are important, but I've found most experienced developers already use them (even if they can't name them). Anti patterns, on the other hand, are a tar pit for even the most seasoned developer. And Java lends itself to grandious designs, full of anti-patterns.
Okay. I'm the first one to claim complete ignorance on the whole "design patterns" fad. I call it a fad because it seemed to come out of nowhere (as most fads do) and everyone was talking about it for a while. Now it's pretty quiet again. So whether or not it really is a fad, it seems like one to a person that never really paid any attention to it. (I just figured it was a lot of noise being generated by the C++/OO/XP crowd.)
I assumed that design patters was a formal way of teaching folks to design their stuff the right way. You know, "here's the way to implement a foo... and here's how you do a bar." Something one step (or level of abstraction) above STL or other popular component libraries.
But that's all me thinking out of my ass. Like I said, I never paid any attention. Why? I never saw a compelling reason to. I don't follow fads. And nobody ever presented a good "here's why you should learn this" argument. I just saw a lot of folks going after design patterns and getting all intellectual and impressed with themselves for being able to use a bunch of fancy new words for the things that probably weren't new at all.
And, well, they didn't teach "Patterns" in my computer science program. I wonder if they do now?
Anyway, now I find out there are Anti-Patterns. Okay, fair enough. They must be the opposite of Patterns. So I followed the link and read the page about Anti-Patterns.
It doesn't tell me anything. Well, maybe a little.
An AntiPattern is a pattern that tells how to go from a problem to a bad solution. (Contrast to an AmeliorationPattern, which is a pattern that tells how to go from a bad solution to a good solution.)
A good AntiPattern also tells you why the bad solution looks attractive (e.g. it actually works in some narrow context), why it turns out to be bad, and what positive patterns are applicable in its stead.
But beyond that it begins to feel really academic in a hurry.
Okay. So it's a collection of "you think you want to do this, but it's actually bad... here's why" stories and rules. Fine. Once you've learned the right way, you get to learn the wrong way too.
K's advice, then, is easy after you've gut thru all the OO babble. Learn the wrong ways to do things so that you can spot them. You shouldn't be re-inventing the same mistakes that others have.
That seems like good advice to me.
Ignorance is bliss. But not always. Sometimes it just makes you feel like you might have missed something important in all the hype.