So if I understand you correctly, you make a distinction between
* The Items collected {cItem}
* the set of items collected (taken as a holonym) {cCollection}; and,
* The container (in which the set logically resides) that provides the set manipulation behaviors. {cCollector}
Exactly!.
MODEL 1
Class "house" has the following attributes
MyBedrooms[5]:room
MyKitchen:room
...
both of which, the array and the single instance are instances of collection classes "room" {cCollector} which contains a collection of items, lets say called "stuff" {cCollection}, each of which item {cItem} is at this stage untyped (but maybe accessable as :object).
Class room::object()
contents:stuff
int contentcount();
object getFirst();
object getNext();
Class stuff::object()
int count();
object item(string objectname);
object getFirst();
object getNext();
...
However, this limits any instance of MyHouse to exactly 5 MyBedrooms, I cant upsize nor downsize.
MyKitchen is again limited to exactly one instance. But they are all instances of the collection class "room". This is the point I'm trying to make. That, from the pov of the "house" class, it can only describe a building with exactly 5 bedrooms and 1 kitchen.
MODEL 2
anyHouse
houseRooms:rooms
where rooms is a collection class, cardinality 1 (from the anyhouse pov), and actual number of realrooms entirely dependent on run time instantiation. So any house has a set of rooms, but the number of them is a run time aspect.
Class rooms
int roomCount();
room item(string roomname);
etc
bruce