[RESOLVED] [2005] Questions about *floating* objects and collections

I had an exciting week last week with a friend of mine who developed an impressive web application. He showed me the object model he created and drew out using visio. Basically he has his base object that contains his business logic and then a collection of Users inside of it. Inside the collection are of course the actual Users as an object (with its own properties, methods, etc...) and inside that each user has more collections (say projects) and even what he called "Redundant Collections" (not sure what he meant.)

Then he had what he called "floating objects" that (i'm guessing) had the same properties as his collection objects, but they weren't tied into his Business object (make sense?). I've never really dealt with collections before and I can't seem to find any info about them and how to use them in an application.

I guess my question is how can i efficiently use collections in my project if I wanted to do the same? And what about these *floating collections*. It seems he just can create a user object on the fly (outside of his business object), set the properties for it and then send it to a collection that updates his database.

I'm lost but intrigued at the same time :confused:

If you have ever used an array, you have used a collection.

Not quite sure what you mean by creating a user object on the fly, but it sounds like you create an instance of a class, then add it to a collection that is contained in a class that interacts with his database.

Not sure quite what the question is.

I guess my question would be:

Whats the point of using collections? The only thing I can think of would be to grab all my users during the initial page load and carry them to each page so the database doesn't have to be queried everytime it wants a list of users right?

That's a good reason. In general, a collection would be used to hold things in one organized location, which would make for potentially swifter searching, iterating, etc. Therefore, any data construct that holds a bunch of items is a collection (array, list, queue, stack, etc.). Also, you could see a database as a type of collection, though it is not formally such a thing (not derived from the base Collection class). Any collection object would reside in memory, which is relatively fast access compared to databases, but you will lose much of that speed if you want to "select items meeting this criteria" from a large enough collection, and you don't have the persistance that a database offers. The tradeoff of various speed issues is just one design issue to consider, while persistance is another. I don't think there is any formal right or wrong about any of it.