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'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?
Would you want to build a house by starting with a handful of acorns?
Unless you write software by scribbling hex codes onto a legal pad, then entering them into the front panel of your box a byte at a time, you are probably taking advantage of quite a lot of pre-fab, pre-tested software artifacts that make your job easier. Like editors, compilers, operating systems, libraries, etc. Design patterns, like compilers, are another step toward automating the nitty-gritty details of a software development project. Nothing more. Like other tools, there are times when they're a great help and times when they're innappropriate.
Why would you draw a line in the sand at any particular level of abstraction and say "Beyond this line lies the path to crummy code?" Crummy code was in plentiful supply when assembly was the language of choice, and it will continue to be in plentiful supply when Java sounds as modern as COBOL sounds now. The tools don't create or destroy crummy code - people do. And until we get the people out of the process (hold(mybreath)!=1), software quality will continue to run the gamut.
I've been using the "patterns" as described in books such as the gang-of-4 one for some years, but I'm not actually happy with the whole thing. Beyond all the hype on patterns, it doesn't seem to deliver the level of reusability and abstraction it is supposed to handle (you may say it's my fault as a software designer, but I'm sure the paradigm lacks something - it's definitely not incrementally productive for large scale projects).
It seems that the Aspect Oriented Programming paradigm is getting more attention because people is beginning to suffer with the bloat these patterns cause when used per se. There are some good AOP implementations for Java (AspectJ and Hyper/J), and one for Python (Transwarp, which is quite well engineered, although I couldn't make it work..). I strongly suggest that you take a serious look at AOP if you are a serious software designer.
Design patterns is a very general term. To say you "don't use patterns" is like saying you "don't use algorithms". Programmers use algorithms, and design patterns, whether they know it or not. A programmer who lacks the discipline to study basic programming concepts is indeed lazy, ignorant, and a bad programmer.
Perhaps you meant: if a programmer finds his current methodology satisfactory
It seems to me that patterns, while occasionally useful, are especially useful in a specific domain. Lately a lot of the Java server-side design is accruing patterns that maximize Java and J2EE. While the standard patterns are always there, Singleton, Command, MVC, etc., it helps Java developers know where to expect to put a piece of code. Obviously this is most useful for web-based projects (I'm not so sure about a giant project that some people have mentioned above), but the J2EE Patterns do a pretty good job of ensuring that there's not a ton of code that's duplicated, and that cut/pasting is minimized. Even the Core PHP book has a section on patterns, so I think they're useful for any language. Also, while I appreciate patterns, I try not to design too much on the front end (beyond functional requirements) because it's really only after implementing a solution that you figure out where you can refactor your code. The nice thing about patterns is that you can take them or leave them, and use them as you find them useful. Obviously, patterns are especially useful when most/all of your developers are familiar with the basics and can recognize them. That way you can use abstraction together, and when you document "This is a singleton" people will know what you mean, as well as how it's implemented in a particular language. Theoretically patterns should reduce the amount of surprise in a development project. Although if it's incorrectly implemented, and someone documents "this is pattern x" then that's when the real debugging starts. ;-)
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...
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.
This is not true at all. The whole point of studying design patterns is to study someone else's tried-and-true solution to a software design problem. It is not a substitute for forming ones own opinions. It's a tool for forming informed opinions as opposed to spouting ill-founded nonsense like your average slashdotter.