php-general Digest 10 Feb 2012 17:32:53 -0000 Issue 7683
Topics (messages 316569 through 316569):
Re: What's Your Favorite Design Pattern?
316569 by: Jeremiah Dodds
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
On Wed, Feb 8, 2012 at 12:48 PM, Paul M Foster <pa...@quillandmouse.com> wrote:
> Um, yeah. It's very "meta".
>
> (That's what I love about "The C Programming Language". It's a little
> over half an inch thick in paperback, explains the whole language
> clearly and concisely, and has barely been revised since 1988. I'm not
> sure you could ask for more in a technical book.)
"The C Programming Language" is an exemplary language book -- it's
well-laid-out, and you can pick it up as a complete novice and end up
with enough of a grounding to get you going.
I don't share quite your level of distaste for Design Patterns, or the
GoF book. I found it pretty useful to read through, and was introduced
to some interesting ways of solving problems I had seen before. Minus
Singleton ;) I also found reading through the first part of the book
to be pretty enlightening. It's more than possible that a lot of the
benefit that I got from the book came from the experience-level I was
at when I read it -- I hadn't worked on any systems that I couldn't
fit entirely in my head at the time.
Most of the problems I've had with code that "uses" design patterns
have been with code where the authors used the patterns in a
prescriptive manner -- like they were looking for ways to fit their
problem into a neat architecture that they didn't need and didn't
understand. I don't think they were (or are) meant to be used in that
manner, they're supposed to be part of a shared language for
high-level patterns used to solve particular families of architecture
issues when they're needed. Letting the existing names and
implementations and suggested use-cases of design patterns dictate
your codebase is a recipe for disaster.
I also happen to agree with the idea that the existence of design
patterns can be a language-deficiency smell, but hey, we don't always
get to work with the languages we prefer to work with.
Anyhow, that's my two cents.
--- End Message ---
