At 11:18 AM -0500 1/20/10, Paul M Foster wrote:
On Wed, Jan 20, 2010 at 10:11:18AM -0500, tedd wrote:
<snip>
While I teach OOP, I don't write any OOP for clients. My charge is to
do things quickly and OOP requires a considerable amount of analysis
before creating a solution. In most cases, I don't have the time.
Besides, I'm more of an agile programmer and that doesn't lend itself
well to OOP, IMO.
This is a fascinating viewpoint. It's almost a sideways condemnation of
OOP: "It takes too long to write OOP for customers". (I know that's not
how you meant it.) But I have to agree, with one proviso. I tend to
write mostly procedural for clients because of time constraints. But I
believe part of the reason I do this is because I haven't built generic
OO components ahead of time which lend themselves to being used on
client sites. If I had spent the considerable time to build OO
components which were usable in this context, I'd be happy to use them.
OTOH, MVC (OOP on steroids) is just beyond reasonable in most cases for
client sites.
I will also echo that it takes a lot of time/work to correctly build OO
components, compared to straight functions or function libraries.
Paul
Paul :
My view of the world is limited to what I do, but to me it's almost a
philosophical issue -- what constitutes reusable code and what
doesn't?
I've looked over many OOP routines that provided no useful purpose to
me because their application was so specific that I could not use it
for the problem I was solving. Programmers put these things together
to be totally self contained, but failed to see that their solution
only fits their problem. As such, for me to use their code I would
have to disassemble it and then reassemble it for my own use -- in
many cases taking it back to procedural.
OOP makes sense if you and your client can agree on a final solution
before any code is written. My experience with clients is that first
I usually have to educate them as to what a web page is and then work
to solve their specific problem, which in many cases they can't even
identify. They can only say what they want.
It's not their fault that they don't know what their problem is for
they haven't been trained in problem identification. In fact, I would
prefer an ignorant client over one who thinks they know how to solve
the problem. I often tell clients to just tell me what you want and
I'll work out the solution.
I remember a sign that hung in an old gas station when I was a kid, which read:
Labor:
$10.00 per hour
$15.00 per hour, if you watch.
$20.00 per hour, if you help.
In any event, when dealing with clients who don't fully realize what
their problems are NOR fully appreciate what their needs are, I don't
have the time to work out every detail beforehand so that I can
create an OOP solution before writing the code.
I might also add that writing an OOP solution before identifying the
problem is an effort that will need to be redone later. Not all
solutions should be written in OOP.
Also, just because you can write OOP does not mean that what you
write is better than what the procedural counterpart would be. It
just means that you used OOP to solve the problem.
So, to get back to your statement that I don't have time to write in
OOP for clients, you are correct -- I can't spend the time necessary
to do it.
Cheers,
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
