Re: OOP slow -- am I an idiot?

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@l-i-e.com> 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&#39;re a good person? Yeah, right! ;-) Prove it and get ten thousand dollars: TenThousandDollarOffer.com