Justin Deoliveira a écrit :
I had a look at some of the style model objects implementations. I
notice the equals() methods all look for an instance of the same Impl
class, and not of the actual interface. For example FillImpl:
[...snip...]
Isn't this a problem? If someone comes along with their own
implementation of Fill, this comparison will fail even if they are
identifical in every other case.
The problem is not easy. An important part of the Object.equals(...)
contract is that 'equals' must be symmetric, i.e.:
x.equals(y) == y.equals(x)
Some algorithms, like some Collections, may behave in an unpredictable
way if this condition is not enforced.
If 'x' and 'y' are not of the same implementation class, then we have no
garantee that x.equals is implemented in the same way than y.equals. We
expose ourself to the risk of 'equals(...)' symmetry violation, as well
as some other potential violations like transitivity. Looking for an
instance of the same implementation class in the 'equals' method is a
conservative way to make sure that the Object.equals(...) contract
(especially symmetry) is respected.
If we want to look for interface instead of implementation, then the
details of the 'equals' method must be part of the specification (i.e.
the interface must declares explicitly an equals(...) method, and its
javadoc must explain how the comparaisons must be performed). This is
what Sun do for the java.util.Collection interface.
Martin.
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
