Software "Design Patterns" -- who needs 'em?

[Darren Dirt]

...or more specifically who here actually uses 'em?

Software design patterns (see also http://en.wikipedia.org/wiki/Design_Patterns I guess)

I've heard a lot about them, seen books all over the place that are more specific, like "AJAX Design Patterns" or "PHP Web App Design Patterns" etc.

But "this "criticisms" section kinda speaks to me. It seems like it's an unnecessary additional consideration when it comes to app dev.

I understand if you're in a major project with 10 other devs possibly continuing parts of code that they didn't start, etc. but isn't that adequately dealt with via standards and CVS stuff?

To me "design patterns" almost seems like "the next big thing to label stuff with" to help publishers sell new books with very little profoundly different contents. Like XP (Extreme Programming), only XP can actually significantly improve how certain projects get completed.

I mean, really, is the average dev here gonna benefit at all by trying to incorporate "design patterns" instead of simply listening to the needs of the client, designing the data structure and interaction components to achieve those goals, and refactoring/refinining as necessary...

[Mr. Analog]

Let's see; I can move from project to project with ease if they use the same patterns, write common compenents for different applications, change fundimental components without any problems and quickly rearchitect components. I can't even think how you would write a base control renderer without a factory anymore. Patterns, like many other techniques have their uses but can be misused. They help you develop easily maintainable code, sometimes not efficient code and certainly not quickly written code (well, not at first).

After having worked both with and without patterns I can say that patterns are great for some things but not others. I prefer using patterns when architecting an application or large component that requires collaboration, design patterns allow developers to work in parrallel.

There are a lot of books on the subject, however there is one book that all other books bow to and that is Design Patterns: Elements of Reusable Object-Oriented Software by the "Gang of Four". I own this book and could lend it to you if you like.

[Mr. Analog]

To me "design patterns" almost seems like "the next big thing to label stuff with" to help publishers sell new books with very little profoundly different contents. Like XP (Extreme Programming), only XP can actually significantly improve how certain projects get completed.

Incedentally, the "Design Patterns" have been in the developer headspace for about 10 years or better. Also, I gotta say that of the 3 applications I support the two easy to maintain ones use design pattern elements while the third one is a traditional application. The "trad-app" has the simplest business logic of the three, and yet is the hardest to maintain / change.

So, yeah, I would say that both Tonnica and I use design patterns daily, and so will Thorin when he becomes my Padawan for the latest app I'm wrangling.

[Tom]

To me "design patterns" almost seems like "the next big thing to label stuff with" to help publishers sell new books with very little profoundly different contents

I totally agree, it just a new label for something programmers did anyway.

[Thorin]

Your Padawan?  Yah, 'k.

By the way, "cantBePast" got renamed to "maximumDate".  Which is what I was trying to figure out, which is what sparked the whole hour-and-a-half talk yesterday.  It wasn't the looping that I was looking at - but I would've ended up factoring it out once I found the right variable names.

[Mr. Analog]

Your Padawan?  Yah, 'k.

By the way, "cantBePast" got renamed to "maximumDate".  Which is what I was trying to figure out, which is what sparked the whole hour-and-a-half talk yesterday.  It wasn't the looping that I was looking at - but I would've ended up factoring it out once I found the right variable names.

Maximum Date sounds like a cool show!