Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #24573
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Newsgroups | comp.lang.java.programmer |
| Subject | Re: multiple inheritance in Java |
| Date | 2013-07-02 00:30 -0400 |
| Organization | A noiseless patient Spider |
| Message-ID | <kqtkmm$4ac$1@dont-email.me> (permalink) |
| References | <multiple-inheritance-20130702024630@ram.dialup.fu-berlin.de> <kqtbs2$ou6$1@dont-email.me> <multiple-inheritance-20130702042118@ram.dialup.fu-berlin.de> |
On 7/1/2013 10:32 PM, Stefan Ram wrote:
> 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.
So, just a struct?
>> 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.
Yeah, but they are references to objects with non-final fields.
If thread T1 does cp.color.setR(42) and T2 does r=pc.color.getR()
while cp and pc refer to the same ColorPoint instance (or to distinct
ColorPoint instances that refer to the same Color instance), you've
got a race.
>> 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.
A non-final class in Java can only be changed by *any*
programmer, via the mechanism of extension. For example,
I might write
/**
* A specialized ColorPoint that automatically adjusts
* its "saturation" depending on the distance from a
* designated origin position.
*/
public class RadialColorPoint extends ColorPoint {
...
}
... and suddenly I've got constraints not anticipated by the
original author -- without changing a single line of his code.
With (overridable) accessors I could manage those constraints;
with exposed fields I could not.
>> 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.
"It seems best" isn't a goal, it's at most a whimsy.
--
Eric Sosman
esosman@comcast-dot-net.invalid
Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: multiple inheritance in Java markspace <markspace@nospam.nospam> - 2013-07-01 18:59 -0700
Re: multiple inheritance in Java Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-07-02 00:30 -0400
Re: multiple inheritance in Java Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-07-02 08:17 -0400
Re: multiple inheritance in Java Arne Vajhøj <arne@vajhoej.dk> - 2013-07-04 16:31 -0400
csiph-web