equals(), Sets, Maps, and degrees of equality

[Sean Mitchell]

This is terrible modeling.

Really. Why?

 

[Lew]

Sean Mitchell wrote:
....

I think, fundamentally, that is the problem. I don't think that Dog
or any subclass of Dog should have to be in any way concerned with
how I want to use him in a collection. Although IMO it is reasonable
for Dog to know whether or nor he is the same as another Dog in all
the ways that are important to Dogs.

The core of the issue for me is that the most commonly used
implementations of Set (possibly Map was a poor example, as has been
illustrated by Andreas and others) rely solely on the object's
equals() to determine equivalence.

The core of the issue is that you want to use the wrong entity as your key.

The fault, dear Brutus, lies not in our 'equals()' method but in ourselves.

TreeSet will take a Comparator as pointed out, and so probably this
is good enough, but it seems a little hackish to use a Comparator,
and a SortedSet to solve a problem of equality (or perhaps,
equivalency).

"Seems"? That's a pretty subjective statement without any engineering basis. What is "hackish"? That is the standard solution and why 'Comparator' exists in the API. The burden of proof is on the one claiming "hackishness", along with the burden of definition for such a vague, subjective term, especially when paired with the hand-waving, responsibility-ducking "seems".

I'm here to tell you, there's nothing hackish about using a 'Comparator'. That's a strange sentiment coming from someone who wants to hackishly use the 'Dog' class for a key where he means 'Breed'. Maybe if your model wasn't so tangled and illogical you'd have an easier time of it.

 

[Lew]

Really. Why?

Because you want to use 'Dog' to model 'Breed', and they aren't the same thing at all.

 

[markspace]

Because you want to use 'Dog' to model 'Breed', and they aren't the same thing at all.

That's what I'm getting too form Andreas and Eric. Breeds are discreet
things that ought to be first class objects in a design like this.
Modeling them as just String seems sub-optimal. It's about as bad as
modeling Zip codes as strings or ints. You can, sure, but why not apply
a type to it? Zip codes have just enough structure and invariants that
strings or ints are almost certainly too loosey-goosey.

It's taken me a little bit to understand what they've been talking about
because the original design was straight forward and simple, but the
original design is probably wrong too for anything besides a throw away
example.

 

[Lew]

Because you want to use 'Dog' to model 'Breed', and they aren't the same thing at all.

Also, "age" is not purely an attribute of 'Dog', but of 'Dog' plus "now". It makes no sense to store an age that will be obsolete the instant it's stored. Rather, store the birthday.

 

[Lew]

public interface Kennel
{
void addClient(Client client);
void removeClient(Client client);
boolean isClient(Client client);

void addDog(Client client, Dog dog);
void removeDog(Client client, Dog dog);
boolean hasDog(Client client, Dog dog);

Set<Dog> getDogs(Client client);

Set<Client> getClientele();
Set<Breed> getBreeds();
Set<Dog> getAllDogs();
}

public interface Client
{
String getId();
}
public interface Breed
{
String getId();
}
public interface Dog
{
String getId();
Breed getBreed();
Client getOwner();
Calendar getBirthday();
}