Re: multiple inheritance in Java
markspace <markspace@nospam.nospam> writes:
With private fields, you can enforce some constraint on color and
position. Without it, you'll constantly have to check in every method
if those constrains are still valid or not.
I only deal with cases where no additional constraints are required.
There's other reasons. Public final fields aren't thread safe, for
example, so you're encouraging bad style, imo.
I don't actually know what it means for a field to be thread
safe. But I was talking about final fields (see also below).
Those fields are only written to in the constructor.
You also allow any arbitrary changes to your class this way, and forgo
encapsulation. This also seems bad style.
A class in Java can only be changed by the programmer.
Possibly you are speaking of an instance of that class.
Since the fields I gave where final (see also below),
they cannot be changed outside of the constructor.
What's your goal here?
It seems best to me to implement something this way, and I wonder
whether I have missed potential issues with it.
~~
In a Supersedes post, I already had change my first usage example to:
point.color.setR( 72 );
point.color.setG( 65 );
point.color.setB( 41 );
point.position.setX( 212 );
point.position.setY( 117 );
. This assumes that
color and positional are public but final, and that
r, g, b, x, and y are mutable but private.
?ColorPoint? in a sense ?inherits? from both Color and Position.
With
class ColorPoint
{ public final Color color;
public final Position position; ... }
one does not have to write any additional methods to allow
the calls given above.