Slashdot Mirror

← Back to Stories (view on slashdot.org)

Thinking in Patterns: Download the First Version

Posted by jamie on from the thought-provocation dept.

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...

7 of 82 comments (clear)

  1. file formats by Alien54 · · Score: 1, Interesting
    One minor nit:

    It would be nice if this was in HTML or some similar format instead of Word.

    --
    "It is a greater offense to steal men's labor, than their clothes"
  2. Newsgroup by javaaddikt · · Score: 5, Interesting

    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.

  3. Design Patterns are abstract? by ShaggyZet · · Score: 2, Interesting

    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.

    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?

    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.

    1. Re:Design Patterns are abstract? by Greyfox · · Score: 4, Interesting
      Design patterns alone are not a magic bullet any more than object oriented programming is, or flowcharting or any of the other advances in this industry that were hyped as the magic bullet.

      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?

  4. Aspect oriented programming by Anonymous Coward · · Score: 3, Interesting

    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.

  5. Patterns and Usefulness by spiritualmechanic · · Score: 3, Interesting

    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. ;-)

  6. The book is not good for patterns. by Anonymous Coward · · Score: 1, Interesting
    Unfortunately, I have to say that while Bruce Eckel has done a great job with the book, his presentation about patterns leaves few things to be desired. The main problem is that he has completely forgot what made the Design Patterns books so great. Every pattern in GoF has been described in the same format. The pattern format is always the same and includes the following sections:
    • Name
    • Intent
    • Motivation
    • Applicability
    • Participants
    • Collaborations
    • Consequences
    • Implementation
    • Sample Code
    • Known Uses
    • Related Patterns
    Unfortunately, in Bruce Eckel's work, all this structure is completely missing. This minor flaw makes it not a pattern book. The book is decreased from a pattern book to just a normal textbook!