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.
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.
Most of what we do does not map to Dijkstra's Algorithm, or the Simplex Algorithm, or the Monte Carlo Method.
Most of what we do is solve practical automation problems for people. You know, the kinds of problems that are never going to get the attention of hundreds of Ph.D. students, all intent on outdoing each other in terms of elegance and brilliance.
Most automation problems get worked on by a series of programmers. There's the original developer, and after that person moves on to greener pa$ture$, maintenance staff. In a situation like that, if you can't say in the documentation that the original problem mapped to a certain well-known algorithm, the next best thing is to say that you implemented the algorithm using a set of patterns.
If you do so, then you'll clearly communicate what was done, making it more likely that proper maintenance decisions are made (including, perhaps, the decision to replace the poorly thrown together patterns of the original implementation).
668: Neighbour of the Beast
Nonetheless, programmers often have to solve very similar problems with very similar structures. Design patterns allow us to categorize those problems and structures in a very efficient way. Can they be abused? Absolutely. That doesn't mean you should dismiss the entire dicipline out of hand. I've also found that bad programmers are much less likely to be aware of patterns, as they don't tend to keep up with their profession as well as the good programmers do.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
It might be a more useful way to evaluate "patterns" by asking what it (they) allow good programmers to do.
My background is that I had been using C++ for several years and even had a graduate level OO class (text was Booch) before I read the Design Patterns book. Though a fairly intelligent guy, perhaps I do solve problems a little slowly, but in any case DP was like pulling the scales off my eyes.
DP provided thorough discussion and examples of how OO language features co1uld be put to good use. It answered the question, What is oo good for?
Nowadays, I recommend to anyone learning C++ to read DP so that actually can understand the usefulness of OO languages.
Many many programmers don't get exposed or trained in the way OO. STL code is one way they can get exposed to the possiblities of oo design (though the STL is probably a bit overwhelming and limited). The most popular oo framework, MFC, is written as though the implementers didn't (don't) understand oo and many of the people teaching C++ courses don't understand it either.
Patterns seems to me the most effective way of teaching the possibilities for real-world problem solving with oo. IMHO, of course.
It is by coff... er, will, alone I set my mind in motion...