On Mon, Feb 25, 2008 at 9:20 AM, tedd <tedd.sperling@xxxxxxxxx> wrote:
> At 8:50 PM -0600 2/24/08, Larry Garfield wrote:
> >Design patterns are just that: A formalization of various common patterns
> that
> >come up over and over in programming. Ever get the feeling "wow, I know
> I've
> >written something kinda like this at least three times now?" That means
> it's
> >probably a design pattern of some kind.
> >
> >Studying design patterns helps you recognize a give problem as being
> similar
> >to another, so the solution is probably similar. It also can alert you
> to
> >common pitfalls and common ways around them.
>
> I've read at least a couple of books on the subject and for something
> that's designed to make programming easier, I find it difficult to
> implement.
>
> I'm more like -- "I've written something like this before -- I'm
> going to find my code and alter it" -- type of guy.
>
> I'm sure it's my failing, but I program trees and not forest. From my
> perspective, you plant enough trees, the forest will take care of
> itself. Besides, every forest I've designed ends up a lot different
> than when I started. So I focus on trees -- it's simpler for me.
>
> I think it's good to develop a methodology so that you can reuse past
> code, but the "design patterns' I've read about seem too abstract for
> me.
some of the design patterns are a bit hard to grasp; and even harder to
determine when one might be appropriate to use. i think a common
misconception about people who advocate design patterns is that said
people attempt to use them arbitrarily. while this is undoubtedly true for
some people, design patterns are like anything else; mastery comes
through practice, and practice can be prone to errors.
that said, design patterns are mainly for adding layers of indirection, to
increase flexibility for an exchange of complexity and often times runtime
performance.
and also, there are patterns that are so trivial im sure weve all used them;
even tedd ;) for example, adapter, yes this is the famous, put a square peg
in a round hole pattern, but in reality its very simple,
/// NOTE: contrived example for demonstration only
function origFunction($p1, $p2, $p3) {}
function newFunction($p1, $p2) {
// pass the same thing for $p3 always for the new 'api'
return origFunction($p1, $p2, true);
}
another thing you will encounter studying patterns is subtle differences.
the non-patterns guys will call newFunction above, a 'wrapper'; and while
it is indeed that, 'wrapper' is a generic term. patterns have several types
of wrappers, adapter, decorator, proxy (and more im sure), which all have
different intents. Which brings us to one of the most important aspects of
patterns, a common vocabulary. this is an incredible tool that fosters
communication and enhanced efficiency.
take it or leave it; i think patterns are worth while.
-nathan
