Slashdot Mirror
Thinking in Patterns: Download the First Version
RichMeraz writes "Bruce Eckel has posted his first incarnation of Thinking in Patterns with Python on his website. What a wonderful Christmas present." Make sure to check the list of mirrors before downloading. As Eckel says, "This should whet your appetite to read
Design Patterns "
(or reread it)... classic book, I figure it can't hurt to refresh my memory once a year, and holidays seem like a good time to think in the abstract...
If you've been reading c.l.python for the past month or so, you've been getting a bit of a preview to his work. He's been putting up little pieces of code which are pretty cool and getting advice from the roundtable.
> It's like the difference between Legos and
> carpentry. Sure, it's a little harder to cut
> wood to the right length and you nails or
> screws to put it together, but would you want
> to live in a house made of legos?
From this audience, I doubt you are going to get the answer you are looking for.
.
Bruce Eckel has put his very well written books for download. That's very nice of him. For those of you who can afford, don't forget to buy a copy too, just to show your support/appreciation. I've bought a copy of "Thinking in Java", even though I've never opened the hard copy book. I end up giving it to my brother-in-law.
Patterns are a method of communication. A common language which allows you to say in just a few words what problem you are solving and how you will solve it. Yes, you still need a good algorithm, but that is an implementation detail and not what patterns are all about. They won't make a bad programmer a good one. It will let several programmers work together more effectively, and possibly make it easier to know what the bad programmer intended when you're stuck with fixing his code.
... when an architect sees a client he can spend hours or days determining what sort of house they need to satisfy their needs, but when he returns to his office to converse with his coworkers he need only say "they need a porch" and everybody can get to work on the implementation.
My favorite example of a pattern, from the original "Design Patterns", is the porch. A porch is a transition between the inside spaces of a house & the outside. It should allow you to greet a person at the door, converse with him there, and decide whether or not you wish to allow him into the inner sanctum of your home. It should be at least 6 feet wide, to allow room for a few chairs, a table for a drink or book, and still allow somebody else to pass. It should be close to the street, but not so close that you are forced to be a part of the public street scene. It should have a low wall or divider so that you can be seated and hear what is happening on the street and be a part of it but still maintain your privacy to read a book or converse with friends. The wall should be low enough so that you can stand or move your chair by the wall, and from there see what is happenning, become a part of the public life on the street, greet a passer-by.
Alexander spends several pages describing how a porch is to be used, what problems it solves, how it interacts with other patterns
"Glory is fleeting, but obscurity is forever." --Napoleon Bonaparte
I'll probably get slammed for this, but design patterns are not abstract in any good sense of the word. They are boilerplates that allow infinite monkeys (or bad programmers) to piece applications.
I tend to agree, though not for the same reasons. It a lot of ways, object-oriented programming has gone over the top, in that what would have been simple designs are turned into OO monsters that no one can understand. Patterns are a response to this. They provide a way of classifying and approaching problems in a structured OO way that keeps the programmer focused on the pattern and not on over-engineering a custom solution (spaghetti programming + OOP = ravioli programming). The obvious flaw here is that perhaps such a heavy reliance on OO-ness for *everything* isn't a good idea. After all, it's only certain groups of programmers that find themselves being sucked into the pattern dogma. Other programmers without strict OO hangups don't understand the reliance on patterns.