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...
Use the third link in the story if you just want to get the book. I didn't even see how to get there from the "first incarnation" link the story poster provided.
Uh, it is in HTML, or RTF, if you prefer
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.
While I agree that "Thinking in Patterns with Python" might be a better name, the text is actually titled "Thinking in Python" with the subtitle "Design Patterns and Problem-Solving Techniques".
From the preface, it appears to be a port of "Thinking in Patterns with Java" to Python, with the hope of completing the Python version and then porting it back to Java. He (Bruce Eckel) makes clear that this is not a Python tutorial.
You can get the complete explanation from the horse's mouth, but I figure it'll be slashdotted soon.
Move on. There's nothing to see here.
its 'thinking in python'. the 'thinking in patterns' book is a different link.
My blog: http://jkratz.dyndns.org/~jason/blog/
STL has very little to do with OO design, there is little to nothing in the way of class heirarchy, and the polymorphism is largely static. STL is for the most part about generic and functional programming. I don't agree that it's "limited", but it certainly is "a bit overwhelming" (to put it mildly)
Learn what an algorithm is. Better, learn lots of algorithms. Don't just grab a bunch of patterns out of a bin and slap them together.
Better yet - learn what makes a good algorithm, AND learn proper design patterns and best practices. Yes, you can think on your own while at the same time observing and learning from people who have had the same problems before you did. The authors of the book "Design Patterns" correctly observed that the same problems are being solved over and over again, and it would be helpful to come up with a list of elegant solutions.
I do admit I've seen some poor programmers falling back on design patterns, and what you get is a bloated product thats functionality has been twisted so that patterns could be used. But the problem there is with people trying to force their problem to fit within a pattern.
Plenty of people have had a programming problem similar to the one you are encountering now, and yes, some of them came up with a better solution than you did. A good programmer should be able to come up with his/her own algorithms, but recognize situations where other people have already done it better. Suppose a programmer dies today, and I have to come in and support his code. Personally I'd rather look at code that followed some established best practices, than code that was written by someone who felt he had to reinvent the wheel.
Agreed, though, design patterns are certainly not abstract. They are merely directions on how to apply a decent solution to a problem.