The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Collections and their contents: intimately entwined?

If you have some class, X, and another class, C, which is a collection of Xs, is there any way to avoid C having to know something about X (for example in order to decide where to place X inside the collection)? I actually don't mind it too much if it is so, but exposing some interface to X for C to use also opens it up for other classes, and that's what I'd like to avoid. Any ideas?

Thursday, December 22, 2005
What language are you using?  It sounds like you want to used a nested class.
N Send private email
Thursday, December 22, 2005
C++. You mean next X inside C, or the other way around? I need both available to other parts of the code, so I don't think it is viable in this case, but I'd be interested to read your thinking.

Thursday, December 22, 2005
In C++ you have templates and other than that the container knows nothing.

In dynamic languages the container doesn't care at all.
son of parnas
Thursday, December 22, 2005
Actually in C++ you have to supply (for example) comparison operators in some cases (and from what I remember of Perl, there too), so it isn't true that such a collection knows nothing about what it contains. To be more specific, an stl set needs a functor which orders keys of the objects it stores (though I confess, I don't remember anything from set theory which says that sets have to be ordered...).

As it happens, for the collection I am writing it needs to know more than just "<", "==", and ">". I can live with that just as I can live with having to provide comparison operators for other, more standard, collections, if I have to.

If I can't avoid providing that information then what I am interested in is whether there is something I can do to avoid publishing that part of X's interface to avoid it polluting the rest of the code.

Thursday, December 22, 2005
> As it happens, for the collection I am writing it needs to know more than just "<", "==", and ">".

Then that seems more like application level behavior so there being an intimacy isn't a problem.
son of parnas
Thursday, December 22, 2005
In C++, there really are very few requirements for items that you can put in a container.  The requirements vary by container and are well documented (e.g. operator < is not requried for std::vector).
What do you think the problem is?  And are all of the posters who aren't putting their name the same person?
bmm6o Send private email
Thursday, December 22, 2005
Also, if you are only concerned about publishing an interface that other might then "exploit", you could make the required functions private to the contained class, and then make the container a friend of the contained class. That way no one but the container can use those functions. This becomes a bit of a maintenance issue if you get more than a few containers though, and overall I don't think I'd recommend it. But, it sounds like it could be something like what you are asking for.
Dave Send private email
Thursday, December 22, 2005
I don't understand the question. Aren't all "standard" collection types capable of storing something without having to know anything about it? After all, how could the language/framework creators know anything about your implementation?

In Java you would use the Vector class and in .NET the ArrayList class. Is there some reason why these (or some similar language construct) won't work for you?
Turtle Rustler
Friday, December 23, 2005
Depends on the type of collection you want. A generic collection doesn't need to know anything - an arraylist/vector is your basic linked list. Adding a member is O(1), and finding a member is O(n).  There is no intimately intertwining involved.

If you want something less generic to get faster access to a member, you'll want to implement the IComparable type functions (<, >, ==) so you can get start using trees.

If your object has a hashable key, then you can use a hashtable for quicker access.
Saturday, December 24, 2005
Maybe this is what you want:
Saturday, December 24, 2005
Thanks masharpe, that was exactly the kind of thing I was looking for!

Tuesday, December 27, 2005
If you're putting your objects into a hashtable, then the collection class needs to know how to appropriately generate a hash from your objects.

Other than that, I don't think it would need to know anything else about your objects.
BenjiSmith Send private email
Monday, January 02, 2006

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz