On Wed, October 11, 2006 3:28 pm, Stut wrote: > Richard Lynch wrote: >> On Tue, October 10, 2006 6:14 pm, Chris de Vidal 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. > > Ok, so I now find myself in the unusual position of disagreeing with > the > Lynchmeister. Why is this wildly inappropriate? IMHO this is what OOP > is > all about. > > You can encapsulate everything to do with a customer in an object. > This > ensures that you don't duplicate any code that works on customer data. > You avoid duplication of code. As a result you can ensure data > integrity > because there is only one route to read and write it. > > If this is not what you think OOP is all about, do please enlighten us > as to the error of our ways. Doing this without some kind of cache or some kind of "bulk load" of multiple customer data is inevitably going to lead to having a zillion "customer" instances floating around in one script to calculate something not readily expressed in an SQL aggregate. See other thread regarding 100 orders with all related uploaded files for an example. It's not so much that having a "customer" object is wrong, as that having ONLY a "customer" object to deal with an application that deals with MUCH MORE than a single customer at a time is wrong. You're going to end up having a TON of duplicate code for a single customer and multiple customers, or you're going to swamp your machine with way too many instances of a do-nothing object for the sake of being "OOP" And, in point of fact, unless you spend the majority of your time/energy in your application dealing with one customer at a time, it's quite likely that your one customer at a time can be encapsulated in a much more re-usable generalized notion of a "set" of customers -- albeit a set with only one element, and with a few specialized functions for certain operations with only work for one-element sets. Objectifying "customer" is the immediate, obvious, and totally inappropriate solution to needing to deal with not just one customer, but with sets of customers, some of which may, or may not, need special handling for a set with one element. This is merely the most obvious example of what is *probably* the needs of the original poster. One problem with OOP is that you really do need to understand very very very well the full scale and scope of your application before you can architect the appropriate OOP model. Its entirely possible that he does not need sets of customers, but needs some OTHER OOP model -- And there's no way to know without knowing the full scope of the project. You can do a bunch of simple object stuff in an iterative design, scale, scope interaction for rapid prototyping, but you have to be prepared to scrap all that code once you figure out what you REALLY wanted to do for your application, and you build the REAL application with the correct OOP model. Some Free Advice for a beginning OOP scripter. #1. Play around a lot with OOP on some non-mission-critical toy projects to get the feel of it. Build the smallest silliest OOP thing you can think of, and push the limits of class inheritence and how the pieces can be fit together in unusual ways. #2. Don't use a 'class' in a real project until you find yourself typing code that does almost the same thing as code you typed before, only it's just enough different to make an include or function unwieldy. At that juncture in time, figure out how you could relate the code you are typing NOW to the old code, and what common components you can abstract out to a "base class" and which parts are "specializations" of the "base class". Re-code both chunks of code as OOP. *THAT* is the real power of OOP. Don't get me wrong: There are some other other uses of OOP, such as a substitute for namespaces for code for public release. But the "obvious" one-to-one mapping of real-world things to OOP classes seldom works out very well, unless your whole application is all about exploring/defining the relationships among those objects, rather than doing something complex with those objects. I *still* don't see OOP as a Right Answer for spitting out HTML web pages in optimized minimalist time frames... Maybe my brain just got warped by all that AI/Lisp work I did for a couple decades, but it feels to me like a bad selection of weapons for the task at hand, most times I see it in PHP. [shrug] -- 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
