Use of internal direct variable access, or using accessor methods

[Adam Heath-2]

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.

Of course, this kind of design pattern needs to be imployed in the
rest of the code too.

[Adrian Crum]

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.

[Jacques Le Roux]

From: "Adrian Crum" <[hidden email]>

> 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.

+1 for accessors

Jacques

[Adam Heath-2]

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.

[Adrian Crum]

Adam Heath wrote:

> 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.

Those are very good points. Thank you for the reminder.

[Marc Morin]

I generally like to use the gettor/settor exclusively,  even from within the class hierarchy.  Makes it consistent.
----- "Adrian Crum" <[hidden email]> 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.

[Bilgin Ibryam-2]

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),

How can making an instance variable final force using accessors? Do you
mean private instead of final?

Bilgin

> then the base class
> always must use the accessors.
>
> Of course, this kind of design pattern needs to be imployed in the
> rest of the code too.
>  

[Jacques Le Roux]

From: "Bilgin Ibryam" <[hidden email]>

> 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),
> How can making an instance variable final force using accessors? Do you
> mean private instead of final?

Yes certainly, since final would  mean they will never change once assigned.
Jacques
 
> Bilgin
>
>> then the base class
>> always must use the accessors.
>>
>> Of course, this kind of design pattern needs to be imployed in the
>> rest of the code too.
>>  
>

[Jacques Le Roux]

From: "Jacques Le Roux" <[hidden email]>

> From: "Bilgin Ibryam" <[hidden email]>
>> 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),
>> How can making an instance variable final force using accessors? Do you
>> mean private instead of final?
>
> Yes certainly, since final would  mean they will never change once assigned.
> Jacques

Though I just thought that if the final is actually referencing an object, accessors may be used to get/set the value of the object
Jacques
 

>> Bilgin
>>
>>> then the base class
>>> always must use the accessors.
>>>
>>> Of course, this kind of design pattern needs to be imployed in the
>>> rest of the code too.
>>>  
>>
>

[Adam Heath-2]

Jacques Le Roux wrote:

> From: "Bilgin Ibryam" <[hidden email]>
>> 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),
>> How can making an instance variable final force using accessors? Do
>> you mean private instead of final?
>
> Yes certainly, since final would  mean they will never change once
> assigned.
> Jacques

If the class is extensible, and a variable is final, but still might
need to be overridden, then it needs to be accessed thru a method.

>
>> Bilgin
>>
>>> then the base class
>>> always must use the accessors.
>>>
>>> Of course, this kind of design pattern needs to be imployed in the
>>> rest of the code too.
>>>  
>>
>