|
|
Posted by "Satyam" on 09/20/05 00:20
""Chris W. Parker"" <cparker@swatgear.com> wrote in message
news:97FD54B5E57A1842AA1A4B232E4761178366@ati-ex-02.ati.local...
Jay Blanchard <mailto:jay.blanchard@THERMON.com>
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.
Navigation:
[Reply to this message]
|