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...
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.
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
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.
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
I think your response is a bit harsh. If people have been successfully using algorithms and design patterns without studying them than that weakens the case for saying that every programmer that doesn't study them is "lazy, ignorant, and a bad programmer".
In any case, I think the case for studying design patterns is a bit weaker than that for algorithms which has stood the test of time.
There's so much competition for programmers' attention these days it's hard to tell the latest fad from something of real value. I'm sure advocates of every programming paradigm believe everyone should rush to study it, but the reality is that there just isn't enought time. So we each have to make our own judgement about what is important and we should avoid labeling others just because they don't share our enthusiasm for a particular method.
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...
The problem is that patterns are not really a new thing, they are a way of expressing tried and true software design concepts. Patterns are not going to radically change the world (because they're not a new thing), but having someone bother to write down advanced programming techniques does make it easier for programmers to learn about software design.
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.
I think a lot of people on here are missing the point of design patterns. Patterns are not a replacement for *algorithms*, they are tools, or better yet, a common language, to describe how objects relate to each other and their basic purposes.
The porch example above, you will notice, says nothing of how to construct the porch, merely how it relates to the house and the people. It is not meant as a replacement for a skilled carpenter who knows how to create a porch that can withstand the weight needed or how to pour the foundation so that it lasts 30 or 50 years.
So the fact that a contractor or architect can use the language "they need a porch" has very little bearing on the quality of the implementation of that porch. Of course, when building systems, if you can say "he needs a porch (or a factory, etc), you don't need to spend days or weeks figuring out what a porch does, and you can actually focus on how you will implement this porch.
The fact that you are using an example in C doesn't help your argument. Nothing stops an OO programmer from reading others' code to see implementations of algorithms OR patterns. I don't know where the comment "...in the object-oriented world, people do not want to be bothered with the problem of reading others code, or thinking for themselves.." is coming from but that has certainly not been my experience with programmers in the OO world.