""Chris W. Parker"" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] Jay Blanchard <mailto:[EMAIL PROTECTED]> on Monday, September 19, 2005 10:40 AM said:
> [snip] > Where I get tripped up is when I realize I'll need to at some point > get more than one customer at a time and thus I want to add a method > called 'get_customers()'. > [/snip] > Why, at any point, would you need to get more than one customer? Good question. When I need more than one customer is when I'm displaying them all on an administration page. Maybe a better example class would be Products. One individual product is displayed on the product's detail page, but in the search results I'd normally be using the same Product class to display all the results which forces me to create a 'get_products()' method. ----------------------- The > signs don't seem to show up on this reply, sorry. Anyway, I have often found the need to make an object and a collection of the same kind of objects. A Customers class containing Customer items, Products and Product. Usually, the collections all look quite the same, they have the Add (which gives me a brand new initialized item object) , Find (which returns another instance of the Customers class, this with a subset of the whole collection), Get (returns and individual item based on a key), Delete (you cannot ask an object to delete itself while you are having a reference to it), Update (call the Update method of the modified items), then, if the language allows, a means to iterate over it and posibly some sort alternatives. Beware, though, that this sounds nice and proper except when the collection starts loading and taking up memory. Then you can handle several strategies, the first is 'load as you go' or 'on demand'. If nobody asks for it, don't load it. Then, you can load the properties on demand as well. You might only load the primary keys first, to be able to enumerate them and then load the rest of the properties when the get_xxxx() function is called. Actually, from an SQL standpoint, it is better to subdivide your fields into those which are used most often, and have them loaded as a group, then several sets of specific fields, groups that usually go together (like an address record, if the street is accessed, there is a good change that the zip will also be accessed, so, load them both when either one is read. Several internal flags should keep track of which set of fields are loaded for each set. Sounds terrible? Yes, it is. It is much faster to rely on the SQL server to handle most of the job of these collections. If you are just sequentially fetching records to show on a listing, it is easier to let them come from the database, a record at a time, and send it right to the client, using and reusing the memory of the resultset over and over. Much faster than loading them in either an array or a collection and then showing them from there. Specially if using them in an environment like a web server where the connection is not persistent and whatever gets loaded in response to a page request gets lost after that is handled. They are much more usefull in batch processes, where you can hold of to that information for quite a while, and it is worth to have it handy. But we don't do that kind of processes any longer these days. Satyam > One > answer is that all customers or a group of customers will need to be > updated/edited with the same information. Therefore you need a > seperate class for multiple customers which could then be extended by > group. A group of customers is a seperate object. Make sense? Well, yes I think it does, but what I'm missing is how this new object interacts with the original one if it does at all. And what would I call it? 'Multiple_Customers'? Or.. perhaps just 'Customers'! :) Do I extend the Customer class or is it a stand alone class? Thanks, Chris. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
