Re: Suggestions for class design

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



""Chris W. Parker"" <cparker@xxxxxxxxxxxx> wrote in message 
news:97FD54B5E57A1842AA1A4B232E4761178366@xxxxxxxxxxxxxxxxxxxxxx
Jay Blanchard <mailto:jay.blanchard@xxxxxxxxxxx>
    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


[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux