But in your solution you're right,
there is only need to store references. But i'm not sure if this solution
is
safe, because we have references to the same important data from two sets
keySet and valueSet, so we have to be careful with them. Mapping object
to
the same object does not have a big sense, for example what about the
method
put when the key already exist, after this operation we have a map where
key
and value are different, so we have inconsistent data.
But what do you provide as the second argument to put()? If
you always write put(obj,obj) there will never be any kind of
mismatch. Yes, sometimes put(obj,obj) might replace an existing
oldobj->oldobj mapping -- but if you didn't want that to happen,
you shouldn't have called put() in the first place!
You can't use put(obj, obj2), because it doesn't have any sense in this
case. When you have the normal key and value, it has a sense.
What about clients, who want also get functionality?
We have to return Map<T, T> in the interface. How can you be sure that
clients won't call put(obj, obj2), you don't have control on it. You can't
throw exception when this occures with easy. So it might be more mistakes
about this. Also you must desribe this strange mapping in javadoc and be
sure that everyone understand it. You can instead public only a Set and a
get method, and hide a map implementation from the client. [...]
operation `T get(T)'. Very well: The suggestion is that you go
internally. There is no need to expose the internal Map to the