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.
Posted by jzawodn at January 08, 2003 12:34 PM
In defense of patterns... (not that you really attacked them though)
Ah, yes, BGSU missed the bus on design patterns. I regret not having some introduction to them while I was there. And I too had the same general feeling that patterns were just a faddish waste of brainpower---until a few years ago.
However, they are incredibly useful as a lexicon of simple design solutions commonly used in practice. Although the 7-page description of the Singleton pattern (and others) in the Gang of Four book is complete overkill for anyone with an ounce of OO experience, it is also useful as a formal description---not just for instructional purposes, but for purposes of discussing designs with colleagues as well. If I say, "Oh ya I used Visitor here, and Proactor over there," it's a lot better than getting bogged down in specific details of a specific language by saying something like:
So then I constructed a mechanism to dispatch appropriately on the type of message using a type-handshaking scheme involving an instance of a subclass of MessageType and an instance of a subclass of ServerStatus---for example, if the server is in 'restricted' mode and I try to perform a privileged operation, an exception is thrown. Then I created an asynchronous I/O-handling subsystem to handle completions of asynchronous read requests, to serve the information back to the user while maintaining responsiveness; to do this I wrote a class that...
Just for example. ;)
As you mentioned previously, Java programming (and high-end OO programming in general) involves, potentially, multiple levels of abstraction. A well-understood, formal specification for particular pieces of commonly-used design ("design patterns") can be incredibly useful in understanding such a system (assuming, of course, it leverages these principles and is well-designed itself), even though when you read pattern descriptions you often find yourself saying, "Duh... but of course! Why would anyone do it differently?!"
I've also found that lazily leafing through pattern descriptions can sometimes spark new, clever ideas about where to apply them in a current project---even when I've already internalized and used them regularly in my designs.
You can also often reuse pattern code, and if patterns have standard names and architectures it's easier to find or interchange the implementations that you use. I won't comment further on this, except to say that there are some difficulties here, as many patterns have behavioral or architectural components that can't be described as a stand-alone class or set of classes. (Enter the need for aspect-oriented programming, generic programming, generative programming, and other "post-object technologies.")
But I've written far too much. Guess I need to get my own blog. :P
Design Patterns are tried and tested ways of organising code. I think they're pretty cool, but I've only ever used a couple of them in a piece of undergraduate coursework so don't take my word for granted ;) The classic pattern everyone has heard of is Model View Controller which does make a lot of sense.
As far as I can see, the most valuable thing design patterns provide is a common vocabulary for teams of OOP coders to communicate their system designs. Of course, this relies on all members of the team knowing the patterns. The classic book on design Patterns is the so called "gang of four" book entitled Design Patterns, and it really is worth flicking through if you're ever likely to encounter patterns in the real world.
Where else could you get a cool term like functor than design pattern books though!
Design Patterns are by definition things that are not going to make you go "Oh wow, I never knew that" if you're at all experienced. There's some value in recognizing something as a pattern but probably not as much as people think. I'm sure your CS program does teach it -- the idea being that new programmers will have a leg up since they can short cut the experience / suffering that old timers like you and I spent figuring this out. OTOH, design patterns get misapplied alot because people don't have the experience -- their design becomes a "How many design patterns can I cram in this" affair.
Anti-patterns are somewhat better because not only do they tell you what not to do (they have cool names like "The God Class", "Golden Hammer" and Corncob) but also what is likely to lead you to fall into them. Nobody sets out to create a "God Class" -- it happens over time usually by a bunch of people.
I'll agree that most experienced developers know and use some design patterns without ever having formally learned them. However, going into it skeptically, I invested a couple days to read the Gang of Four book awhile back. It was very helpful to see these patterns spelled out and described in full because it gave me a more conscious awareness of what I was actually doing (always a Good Thing).
If you're moving from a barely-OO language like Perl to a hardcore-OO language like Java, I'd really recommend at least browsing the book. Also, the Refactoring book was even more helpful for me (since a large part of my job was maintaining existing crappy code).
Don't diss perl's OO - it's different to Java's, I'll grant you that, but no less powerful for it. Check out Damian Conways book on OO perl.
There are also plenty of sites showing how to apply design patterns in Perl. Google will hunt them down for you.
Like many other ideas in the world of programming (e.g. XP, Refactoring, UML), Design Patterns are some people saying, "We've done a lot of programming. Here is an approach that we've found helpful."
You might find it to be invaluable, and you might find it to be trash.
But given its influence and popularity, even eight years (!) after its first publishing, it's probably worth a look.
FWIW, I found Design Patterns Explained to be a friendlier, more readable introduction, especially because I do not know C++ beyond a novice level.
I dont know what the fuck all youz guyz are talking about but it sounds horribly lame.
Advice for Jeremy: go buy some weed and masturbate to those half-hour infomericals for Sex hotlines they show on TV after midnight.
You'll have a lot more fun than talking about this mindless Jibber-Javver.
