Adrian Crum wrote: > Adam Heath wrote: >> ComparableRange has inconsistent access to the instance variables of >> other ComparableRanges. There are several methods that do some kind >> of comparison with another range. Sometimes, those methods call the >> accessor methods. Other times, direct variable access is used. >> >> Here's my take on this issue, based on the Concurrency in Practice >> book. If ComparableRange is final, and not meant to be extended, then >> always do direct access, period. If ComparableRange is supposed to be >> extended by other classes, then make the instance variables final(to >> force extended classes to use the accessors), then the base class >> always must use the accessors. > > Consistency would be nice. My personal preference is to avoid making > classes final because a user might want to extend a class's behavior.
That makes writing correct equals() and hashCode() very difficult. a.equals(b) == b.equals(a) has to hold. a.hashCode() == b.hashCode() If the classes implement Comparable, then when a.equals(b), a.compareTo(b) == 0 and b.compareTo(a) == 0. When subclassing, and the subclass adds something that changes what equals is based on, then all the other methods also have to be changed, and all subclasses still have to obey the contracts outlined above.
