Equals vs the Encapsulation Boundary
| Line 7: | Line 7: | ||
== What is the problem? == | == What is the problem? == | ||
| − | In Java, two classes can be compared if they are equivalent by comparing the relevant data fields in each class. This breaks object encapsulation. | + | In Java, two classes can be compared if they are equivalent by comparing the relevant data fields in each class. This breaks object encapsulation if you want to compare normally inaccessible fields. |
== How can we solve this? == | == How can we solve this? == | ||
| Line 16: | Line 16: | ||
If object encapsulation is good: | If object encapsulation is good: | ||
| − | * We can provide a subclass-able Comparator class that can provide comparisons of equality between two provided objects of a class. This means that any fields that need to be compared need to be made accessible, probably in the form of getters. | + | * We can provide a subclass-able Comparator class that can provide comparisons of equality between two provided objects of a class. This means that any fields that need to be compared need to be made accessible, probably in the form of getters. An analogy... Two people stand beside each other, in order to determine the relative straightness of their teeth, either, one needs to look at the other and also have a mirror, or someone has to look at both of their teeth for them. |
* Other solutions? | * Other solutions? | ||
== Is this a more general problem? == | == Is this a more general problem? == | ||
Is this a more general problem with object encapsulation? Is it not a problem at all? | Is this a more general problem with object encapsulation? Is it not a problem at all? | ||
| + | * Stephen would argue that this is a general problem with object encapsulation. Other groups of methods will have the same problem. | ||
| + | * Matthew would argue that this is not a problem at all. If objects want to compare themselves then the type of information they want to compare is stuff that should be available anyway. | ||
| + | |||
| + | == A Possible Example == | ||
| + | We have a pseudo-random number generator. The class is implemented with an algorithm using a seed and a location in the sequence. It provides the methods 'currentRanNum()' & 'nextRanNum()'. Assuming we want to compare equivalence of two of these objects, we don't want to just compare the current random number as the objects will appear to be equivalent, we need to look at the seed and the location in the sequence to discover if they are actually equivalent. | ||
Revision as of 05:06, 30 July 2009
If we make the assumption the Object encapsulation is preferred we end up in a slight conundrum... Java's Object class provides a over-ridable method 'equals(...)' in which the current object compares itself with a provided object for equality and/or equivalence. We assume an ideal language.
Contents |
What is equality?
Equality/equivalence (they are slightly different) can fall into two distinct categories:
- Two objects are 'equal' if they are the same object. (Equality)
- Two objects are 'equal' if certain properties of each object have the same values. (Equivalence)
What is the problem?
In Java, two classes can be compared if they are equivalent by comparing the relevant data fields in each class. This breaks object encapsulation if you want to compare normally inaccessible fields.
How can we solve this?
Various options exist:
- We can decide that object encapsulation is bad.
- We can decide that object encapsulation is good, but provide an exception.
- We can decide that object encapsulation is good.
If object encapsulation is good:
- We can provide a subclass-able Comparator class that can provide comparisons of equality between two provided objects of a class. This means that any fields that need to be compared need to be made accessible, probably in the form of getters. An analogy... Two people stand beside each other, in order to determine the relative straightness of their teeth, either, one needs to look at the other and also have a mirror, or someone has to look at both of their teeth for them.
- Other solutions?
Is this a more general problem?
Is this a more general problem with object encapsulation? Is it not a problem at all?
- Stephen would argue that this is a general problem with object encapsulation. Other groups of methods will have the same problem.
- Matthew would argue that this is not a problem at all. If objects want to compare themselves then the type of information they want to compare is stuff that should be available anyway.
A Possible Example
We have a pseudo-random number generator. The class is implemented with an algorithm using a seed and a location in the sequence. It provides the methods 'currentRanNum()' & 'nextRanNum()'. Assuming we want to compare equivalence of two of these objects, we don't want to just compare the current random number as the objects will appear to be equivalent, we need to look at the seed and the location in the sequence to discover if they are actually equivalent.
