By the way, about myself. I'm primarily a system administrator. Most of the time I USE code, NOT
write it. But I also dabble, and right now we need to improve our old custom PHP revenue
application which has sat stagnant for a few years. We can't afford a full-time programmer and I
know enough to be dangerous ;-) So I'm the guy.
All that to say I'm no pro and am humbly asking your collective professional opinions.
--- Richard Lynch <ceo@xxxxxxxxx> wrote:
> > I want to create a "customer" class which fetches its attributes from
> > a MySQL database.
>
> No, you don't. :-)
>
> This is a classic example of the "obvious" OOP solution being wildly
> inappropriate.
I'll consider that possibility.
> Start thinking more in terms of what you want the whole application to
> do, and build classes that do THAT, rather then starting with a single
> customer and their info.
It seems you are advocating procedural programming here. I don't see how your use of classes are
anything more than glorified functions. I could re-word the sentence above thusly:
> Start thinking more in terms of what you want the whole application to
> do, and build [functions] that do THAT...
That's the path we went down at first and the net result was data access functions being copied
and modified all over the place, making maintenance a real chore.
Did it have speed? Yes. Do I hesitate to make changes to it? Yes. In a world where I am forced
to choose between speed and maintainability, I'll probably choose speed, particularly when the
program will be used daily. However, I truly believe a speedier OOD is attainable, which is why
I'm asking.
If, however, you are talking about some blending, where I create a procedural-style class and then
make any modifications in subclasses which override the parent class, like this:
class parentFunction
{
getRevenueForCustomer ($id)
{
// SELECT * FROM customer_revenue WHERE customer_id = '$id'
}
}
class childFunction inherits parentFunction
{
// Overriding the parent function
getRevenueForCustomer ($id, $year, $month, $department)
{
// SELECT * FROM customer_revenue WHERE customer_id = '$id' AND year = '$year' AND month =
'$month' AND department = '$department'
}
}
If that's what you mean, I honestly can't see how that saves coding time or helps maintenance,
unless I need to also use some extraneous code with every query which would be included into the
constructor. But then I could also use a function (instead of a class) which is like a query
wrapper:
function sql_query ($query)
{
// Some massaging routines
// ...
// Some more
// ...
$result = mysql_query ($query);
// Error handling routines
// ...
// Other routines
// ...
return $result;
}
sql_query ("SELECT * FROM ...");
If that's the case, I don't see the need for classes at all, and that's actually the path we went
down at first. We created a query function which massaged the input and handled errors. I've
since learned that's not what I really wanted to do; I want to handle errors elsewhere. I think
the above is easier to understand than using a class.
Anyway, tell me what you have in mind.
CD
Think you're a good person? Yeah, right! ;-)
Prove it and get ten thousand dollars:
TenThousandDollarOffer.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
