On 10/13/06, Stut <[EMAIL PROTECTED]> wrote:
Ed Lazor wrote:
> ...Or is it something else entirely; I dunno, maybe
> UserCollection has a property defined as an array of User class? I
> think that's what people were saying earlier in the thread as being a
> "very bad thing" in terms of memory utilization, etc.
I'm honestly having a difficult time thinking of any way *other* than
having an array of User objects. In previous projects I've tried the
route of (like Richard mentioned early on):
class Customers {
var $ids = array();
var $names = array();
}
But found it very cumbersome and unintuitive when dealing with a
single Customer. Moreso I got lost when I didn't know if I were
dealing with one or many customers...
As soon as I went to a Customer and CustomerCollection approach, I was
able to make sense of it all. Even though CustomerCollection usually
didn't actually exist, except conceptually as an array of Customer
objects within my application code. Like Stut suggested, I too have
static fetch functions derived from the base ActiveRecord class that
return arrays of objects.
Maybe all of my applications have been "simple" enough in that I
tended to work on single objects 95% of the time, and therefore
creating interfaces for those single objects made sense. I think
that's what Ed means by situational?
It is occuring to me that perhaps all of my bias is centered around
the fact that I always create my models as children of an ActiveRecord
class, which is by nature based on *one record* of a table.
Is there an ActiveTable class that, if implemented, might completely
change everything???
Until then, I'm not convinced: constructing a basic building block
such as a Customer, and then an aggregate block such as a collection
of Customers, and so on, seems the most stable and scalable approach
almost without exception...and perhaps, with that, I'm revealing the
extent of my OOP naivety...
John W
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
