On Thu, October 12, 2006 8:24 am, Chris de Vidal wrote: > [use the archives] I can't architect a good OOP solution to a problem that hasn't been fully defined, any more than one can architect a house without knowing all the rooms that are needed... I agree that all the code samples you provided below are "wrong", if that helps. :-) If getRevenueForCustomer is all you need, then I'd have optional args for year and other factors, and have just one query and one function, and it does the right thing for that one customer. I'm assuming you need a heck of a lot more than that, though, so the above paragraph is not particularly helpful. The problem with an OOP discussion like this is that you have to have a complete understanding of what needs to be done before you can make sensible statement about what do do. It's POSSIBLE that "class customer" is the "right answer", though I doubt it based on your original post about performance problems from having too many instances floating around. Maybe others' analysis that "class customer" was right, but not having the database access optimized with cache or with aggregators or something was the true problem. Maybe I even have a point about using "class customers" and operating on sets, even if it means specializing on the one-element-set. There's no way anybody can say for sure, not knowing the full scope of the application, though. -- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some starving artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
