On Mon, Nov 01, 2010 at 08:29:14PM +0000, Vincent Hennebert wrote: > More importantly, I keep thinking that there’s a design flaw in > ColorWithAlternatives. Its equals method breaks the contract defined on > Object.equals since it’s not symmetric. This is bound to cause
That would mean: ColorWithAlternatives a, Color b; a.equals(b) should return the same as Color.equals if b is not of type ColorWithAlternatives or a subclass. Only if b is of type ColorWithAlternatives or a subclass, can ColorWithAlternatives.equals apply its own logic. How can symmetry be assured if the type of b is another subclass of Color which implements its own equals? If the other class applies the same logic (SubclassOfColor a, Color b; a.equals(b) should return the same as Color.equals if b is not of type SubclassOfColor or a subclass), it is guaranteed. > hard-to-track issues in client code. Also, the way equals is implemented > will make it systematically return false if an instance of > ColorWithAlternatives is being compared with an instance of a sub-class, > which may not be the desirable result. Would it be better to use getClass().isInstance(obj), which would be true for all objects which can be cast to ColorWithAlternatives? > Either ColorWithAlternatives is not a Color and therefore should not > extend the Color class; or its equals method should be changed to follow > the contract and the comparison of ColorWithAlternatives instances > should be implemented differently. Would findbugs find this problem? Simon --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
