tedd 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.
Not to say that what you are doing is wrong, but we had a guy here in our office
that was/is a cut/paste master. If he had a routine that he found that (almost)
worked. He would then use that same chunk of code everywhere.
But, if that same bit of code got almost the right answer, he would write a
"fix" that would "get it right" this time. Then the next time he used the
re-written code, he would have to write another "fix". This went on for two years.
When they brought me in to take over managing his code, I re-wrote the entire
lib in one weekend. I have not had to touch the base code since then, and it is
"right" every time. It is much lighter and faster.
The moral of my story, you keep adding floors to your sky riser, the foundation
is not going to support the add structure.
Build yourself a re-enforced foundation, you will never have to worry about how
many floors you have to put on top of it.
All you will need to do is build yourself a structure that deals with the
results returned to you by your base code.
The other day I gave an example of how I use code:
Users::GetGroup($somegroup)->update();
And I got this response
It really sucks for debugging though, because what if
GetGroup($somegroup) returns a null or unexpected value?
The idea is, if you wrote the code, then you force it to return to you what you
want. In this case, if something went wrong in the GetGroup() static method,
the I would return my normal object that has the update() method, at the same
time I would create an exception and catch that upstream.
Probably a little long winded on this one and maybe a little off this topic.
Sorry.
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.
Cheers,
tedd
--
Jim Lucas
"Some men are born to greatness, some achieve greatness,
and some have greatness thrust upon them."
Twelfth Night, Act II, Scene V
by William Shakespeare
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
