Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #24569 > unrolled thread

Re: multiple inheritance in Java

Back to article view | Back to comp.lang.java.programmer

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  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

#24569 — Re: multiple inheritance in Java

On 7/1/2013 5:47 PM, Stefan Ram wrote:
> Supersedes: <multiple-inheritance-20130702021857@ram.dialup.fu-berlin.de>

>    . Would it be so bad to implement this using public fields
>    instead of classical delegation? Public fields:

>
>    . I only ask, because public fields usually are frowned upon
>    in OOP, but what would be the drawback here, especially when
>    those fields are final?
>

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.

There's other reasons.  Public final fields aren't thread safe, for 
example, so you're encouraging bad style, imo.

You also allow any arbitrary changes to your class this way, and forgo 
encapsulation.  This also seems bad style.

You can forgo inheritance if you like, ColorPosition does not have to be 
a type of Position (or Color), but encapsulation seems too basic and 
desirable to give up.  You might be able to make the case for some 
simple examples, but I think problems with this idea would become 
apparent quickly in even a modest sized project.

What's your goal here?

[toc] | [next] | [standalone]

#24573

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

[toc] | [prev] | [next] | [standalone]

#24579

On 7/2/2013 5:49 AM, Stefan Ram wrote:
> Eric Sosman <esosman@comcast-dot-net.invalid> writes:
>> So, just a struct?
>
>    Yes. Recently, I often had this thought, that sometimes
>    structs are appropriate.
>
>>      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.
>
>    How do you know the author of Color has not taken care for
>    proper synchronisation? IMHO, this is a question of thread-safety
>    of the Color class not of the ColorPoint class.

     Not enough, because the constraint applies to both the
Color and Position classes simultaneously.  Even if both of
those classes are individually thread-safe, the combination
isn't.  If actions A1 and A2 are atomic, it does not follow
(in fact, almost never follows) that A1;A2; is atomic.

>> ... 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.
>
>    I see, so I should declare the class final.

     Right.  Inheritance is for *your* benefit alone, and you
should make sure nobody else can use it.  ;-)

-- 
Eric Sosman
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#24627

On 7/2/2013 5:49 AM, Stefan Ram wrote:
> Eric Sosman <esosman@comcast-dot-net.invalid> writes:
>> So, just a struct?
>
>    Yes. Recently, I often had this thought, that sometimes
>    structs are appropriate.

There are such cases.

But existing Java functionality can deliver the
functionality with just some "unnecessary" verbosity.

Unless you also decide to make it a value type like C#.

Arne

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web