I think it also to some extent comes down to having a shared
vocabulary. Pretty much the same way that you know which technique I'm
talking about when I use the word "recursion", which algorithm I'm
talking about when I say "quick sort" and which data structure I mean
when I say "linked list". It's way easier saying "quick sort" than
describing how the algorithms works each time. Yes, you may be able to
come up with a sorting algorithm yourself, but now when I tell you
that there is a sorting algorithm called quick sort you'll either know
which particular sorting algorithm I'm talking about, or you can go
look it up. Various implementations may for instance then employ
different sorts of optimizations to make it work well in one
particular scenario.

Design patterns are called patterns specifically because they are
things that happen to occur frequently in code, i.e. they are
recognizable patterns. It makes sense giving names to such things, and
they exist whether or not you name them of course.

There are a couple of reasons why a design pattern needn't necessarily
yield reusable *code*:
1) They transcend programming languages. A pattern may be implemented
in PHP, Python, Java, C++ or some other language, but particularly how
you would do it depends on which features and language constructs that
are available in the particular language.
2) A particular pattern may be applied to different problems. How you
would apply it depends on the nature of the problem. If we just use
the strategy pattern as an example, you may have different strategies
for an AI in a computer game, you may have different payment
strategies in an online shop and you may have different strategies for
calculating employees' salary. All of these three things are very
different in nature, but they may still use the same an overall shared
pattern that is then called "a strategy".

Tony, I disagree with your notion about design patterns being "mental
crutches". Besides for educational purposes, I see no reason why you
would want to spend time on rediscovering something that someone else
already discovered a long time ago. The point is of course not that
each time you need to do something you'll scour books and various
forms of online resources for a design pattern that fits exactly your
needs. The point is that by knowing these patterns, you'll know that
for a particular problem this particular solution tends to work well.
Indeed as you become more experienced, this will become more
transparent and "automated" so to speak.

You may very well discover or come up with some sort of pattern
yourself (though you might not necessarily give it a name), and you
may even unknowingly do something often that other people call a
design pattern and have given a name. Again, this is exactly the
reason why we call them patterns: they are things that people tend to
come up with, and they tend to work pretty well.

Now because there exists a sort of standard nomenclature, when someone
asks me how they should approach a particular problem I can tell them
to look up a particular pattern instead of trying to (re)explain it
when someone else has already done that in great detail.

I'm sure you can appreciate the benefit of having a shared vocabulary.
It's something that's going on in not just programming, but
practically in every field that exists.

I hope this makes some sense. It's my take on this anyway.

Daniel Egeberg

PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to