multiple inheritance in Java

[Stefan Ram]

Supersedes: <[email protected]>
[edited first »r = 72« to »setR( 72 )« and so on for the next four lines]

Assume you needed a class ColorPoint in Java:

class ColorPoint extends Position, Color;

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

{ public final Color color;
public final Position position; ... }

, usage:

point.color.setR( 72 );
point.color.setG( 65 );
point.color.setB( 41 );
point.position.setX( 212 );
point.position.setY( 117 );

. Classical delegation style:

point.setR( 72 );
point.setB( 65 );
point.setC( 41 );
point.setX( 212 );
point.setY( 117 );

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

 

[markspace]

Supersedes: <[email protected]>

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

 

[Stefan Ram]

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.

 

[Eric Sosman]

I only deal with cases where no additional constraints are required.

So, just a struct?

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.

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.

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.

 

[Stefan Ram]

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.

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

 

[Eric Sosman]

Yes. Recently, I often had this thought, that sometimes
structs are appropriate.


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.

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

 

[Joerg Meier]

Supersedes: <[email protected]>
[edited first »r = 72« to »setR( 72 )« and so on for the next four lines]

Assume you needed a class ColorPoint in Java:

class ColorPoint extends Position, Color;

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

{ public final Color color;
public final Position position; ... }

, usage:

point.color.setR( 72 );
point.color.setG( 65 );
point.color.setB( 41 );
point.position.setX( 212 );
point.position.setY( 117 );

I know I must sound like a broken clock by now, but once again I recommend
Lombok, specifically @Delegate:

class ColorPoint {
@Delegate
public final Color color;
@Delegate
public final Position position; ... }

Would then create methods to allow for exactly what you wanted:

. Classical delegation style:

point.setR( 72 );
point.setB( 65 );
point.setC( 41 );
point.setX( 212 );
point.setY( 117 );

More info at <http://projectlombok.org/features/Delegate.html>

Liebe Gruesse,
Joerg

 

[Arne Vajhøj]

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

 

[Jim Janney]

Supersedes: <[email protected]>
[edited first »r = 72« to »setR( 72 )« and so on for the next four lines]

Assume you needed a class ColorPoint in Java:

class ColorPoint extends Position, Color;

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

{ public final Color color;
public final Position position; ... }

, usage:

point.color.setR( 72 );
point.color.setG( 65 );
point.color.setB( 41 );
point.position.setX( 212 );
point.position.setY( 117 );

. Classical delegation style:

point.setR( 72 );
point.setB( 65 );
point.setC( 41 );
point.setX( 212 );
point.setY( 117 );

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

In theory, if this is a simple aggregation of data, with no relationship
between the various parts, then you might as well just make them public.
If there is some meaning beyond simple aggregation, in particular if you
can define one or more invariants for the class, then you need to
encapsulate the fields so that the class can maintain those invariants.

On the other hand, and this is probably more important, the Java
community sets great store on always doing things the usual way, and
this has turned into a strength for the language: you can pull a
third-party library library into a project and expect that it will work
with and follow the same conventions as the rest of the code. There are
languages that encourage the programmer to express his or her
individuality (Lisp comes to mind). Java is not one of them.

 

[Jim Janney]

On the other hand, and this is probably more important, the Java
community sets great store on always doing things the usual way, and
this has turned into a strength for the language: you can pull a
third-party library library into a project and expect that it will work
with and follow the same conventions as the rest of the code.

Recently I've been looking at an interesting exception to this, JSch:

http://www.jcraft.com/jsch/

If you do a little searching on the web you can find lots of complaints
that the code isn't very Java-ish, and on my own reading of the source I
tend to agree. It nevertheless continues to be a successful project
with widespread use, and I think there's a reason for that. SSH has a
well-defined standard and the code is a faithful implementation of
that. Once you study the standards document, the JSch code starts to
make sense. It's also a stable protocol that seems unlikely to change,
so there's not a lot of reason to want to extend it yourself. But most
projects aren't like that.

 

[Lew]

In theory, if this is a simple aggregation of data, with no relationship
between the various parts, then you might as well just make them public.
If there is some meaning beyond simple aggregation, in particular if you
can define one or more invariants for the class, then you need to
encapsulate the fields so that the class can maintain those invariants.

Good points, and indirectly raises to mind that there are many factors that
influence implementation choices like access level. Harping on "in theory",
if the theoretical model is solely semantic then public variables are fine.

In practice, that is with a model that includes more analytical dimensions,
you seal an attribute in a get/set for invariants, yes, but also strictly
internal ones, and also for thread safety, initialization timing, exception
handling, and such other matters not directly connected to the primary
semantic model.

Also in practice, as an idiomatic matter, there are engineering advantages
to using the method approach to attribute implementation.

On the other hand, and this is probably more important, the Java
community sets great store on always doing things the usual way, and

Pish-posh. You imagine an overarching cultural inertia to a community
well known for its fractious insistence on competing worldviews.

What I have observed is that people who speak up on such matters in the Java
"community" tend to be of the "I'm from Missouri, you'll have to show me"
variety.

Turns out the get/set as a routine idiom has all upside and virtually no
downside, so as an engineer one tends to use it, just as in C# you use
its attribute idioms routinely. But "routinely" doesn't mean "mindlessly"
or "superstitiously" or "to meet the 'community's' approval".

this has turned into a strength for the language: you can pull a
third-party library library into a project and expect that it will work

That had better be a strength of every third-party library in every language
for every platform, hm?

with and follow the same conventions as the rest of the code. There are

Code conventions and a library's utility are weakly correlated, I venture.

Internal consistency within the library, sure, but conformity to yours or
another third party's conventions, even in Java, are not really guaranteed,
certainly no more so than in other widely-used languages with good conventions.

languages that encourage the programmer to express his or her
individuality (Lisp comes to mind). Java is not one of them.

Sorry, LISP doesn't have coding conventions?

And what does "express ... individuality" have to do with writing good code?

I mean, perhaps it does, I just don't see its help to code quality. In
decades of working on other peoples' code, the most "individual" code has
been the most bug-riddled and difficult to maintain. I really don't think
there is any evidence of a cultural or political conspiracy toward good
quality code, which by natural selection tends to the better written.

There certainly is a lot of room for style in Java coding, but if you follow
good engineering practices rigidly there will tend to be commonalities with
so-called "conventions". You're going to write complete, thorough, informative
Javadoc comments as a matter of habit. You're going to use get/set methods.
You're going to use a lot of read-only, final, immutable types. You will tend
to use generics. You're going to indent consistently, if not conventionally.
You're going to use version control even for solo projects where you are
producer, director, cinematographer, stars and extras. Every input will be
checked for boundary conditions. You probably even will have written various
sorts of useful tests. And this is true whether you're using Java or the useful
idioms and practices of some other platform.

It happens because you want to write and use code that works, doesn't break,
that you can fix, that you know what, when, where, how and why.

One of the most successful IT businesspeople I ever knew charged a service
contract subscription but only installed stuff that never broke. He was able
to compete heavily on up-front costs because service was a profit center. Plus
he used the service contract as an excuse to stay in close touch with all his
customers. Thus cost of sales was actually borne by the customer, and they
loved it. I can't recall a single customer complaining to him because their
stuff just kept on working without trouble.

 

[Arne Vajhøj]

On the other hand, and this is probably more important, the Java
community sets great store on always doing things the usual way, and
this has turned into a strength for the language: you can pull a
third-party library library into a project and expect that it will work
with and follow the same conventions as the rest of the code. There are
languages that encourage the programmer to express his or her
individuality (Lisp comes to mind). Java is not one of them.

That is somewhat true.

Java is primarily used in business programming. You need millions
of Java programmers and that means that you will get some very good,
a lot of acceptable and some complete hopeless. And the type
of applications are often semi-important (no one will die if the
application does not work but some one may lose money if the
application does not work). In that context it is important that
Java code written by mediocre programmers actually work. So the
Java language is kept reasonable simple, framework are often
pretty strict and there is a lot of emphasis on following
all the conventions. Maybe a bit boring. Bit usually it works.

Arne

 

[Arne Vajhøj]

Recently I've been looking at an interesting exception to this, JSch:

http://www.jcraft.com/jsch/

If you do a little searching on the web you can find lots of complaints
that the code isn't very Java-ish, and on my own reading of the source I
tend to agree. It nevertheless continues to be a successful project
with widespread use, and I think there's a reason for that. SSH has a
well-defined standard and the code is a faithful implementation of
that. Once you study the standards document, the JSch code starts to
make sense. It's also a stable protocol that seems unlikely to change,
so there's not a lot of reason to want to extend it yourself. But most
projects aren't like that.

I am sure there are other exceptions as well.

There must be some code ported from C# or c++ that follow different
idioms and paradigms than standard Java.

But it is exceptions to the rule.

Arne

 

[Jim Janney]

Good points, and indirectly raises to mind that there are many factors that
influence implementation choices like access level. Harping on "in theory",
if the theoretical model is solely semantic then public variables are fine.

In practice, that is with a model that includes more analytical dimensions,
you seal an attribute in a get/set for invariants, yes, but also strictly
internal ones, and also for thread safety, initialization timing, exception
handling, and such other matters not directly connected to the primary
semantic model.

Also in practice, as an idiomatic matter, there are engineering advantages
to using the method approach to attribute implementation.


Pish-posh. You imagine an overarching cultural inertia to a community
well known for its fractious insistence on competing worldviews.

What I have observed is that people who speak up on such matters in the Java
"community" tend to be of the "I'm from Missouri, you'll have to show me"
variety.

All language communities are fractious, the Java community is far more
united than most. Truly, you have no idea

Turns out the get/set as a routine idiom has all upside and virtually no
downside, so as an engineer one tends to use it, just as in C# you use
its attribute idioms routinely. But "routinely" doesn't mean "mindlessly"
or "superstitiously" or "to meet the 'community's' approval".


That had better be a strength of every third-party library in every language
for every platform, hm?

One would like to think so, but in many languages mixing code from
different vendors can be a major headache.

Code conventions and a library's utility are weakly correlated, I venture.

Internal consistency within the library, sure, but conformity to yours or
another third party's conventions, even in Java, are not really guaranteed,
certainly no more so than in other widely-used languages with good conventions.


Sorry, LISP doesn't have coding conventions?

Yes, lots. Even more than C.

http://lmgtfy.com/?q=lisp+coding+convention

But none with the official cachet of the Oracle document.

And what does "express ... individuality" have to do with writing good code?

Perhaps I should have said that Lisp rewards such efforts more than
Java. Any language that can redefine its own syntax at run time is
necessarily going to be malleable, and in the right hands this can be
extremely powerful. Paul Graham has written extensively on this
subject. In Java, as you proceed to point out, this is not so evident.

I mean, perhaps it does, I just don't see its help to code quality. In
decades of working on other peoples' code, the most "individual" code has
been the most bug-riddled and difficult to maintain. I really don't think
there is any evidence of a cultural or political conspiracy toward good
quality code, which by natural selection tends to the better written.

There certainly is a lot of room for style in Java coding, but if you follow
good engineering practices rigidly there will tend to be commonalities with
so-called "conventions". You're going to write complete, thorough, informative
Javadoc comments as a matter of habit. You're going to use get/set methods.
You're going to use a lot of read-only, final, immutable types. You will tend
to use generics. You're going to indent consistently, if not conventionally.
You're going to use version control even for solo projects where you are
producer, director, cinematographer, stars and extras. Every input will be
checked for boundary conditions. You probably even will have written various
sorts of useful tests. And this is true whether you're using Java or the useful
idioms and practices of some other platform.

It happens because you want to write and use code that works, doesn't break,
that you can fix, that you know what, when, where, how and why.

One of the most successful IT businesspeople I ever knew charged a service
contract subscription but only installed stuff that never broke. He was able
to compete heavily on up-front costs because service was a profit center. Plus
he used the service contract as an excuse to stay in close touch with all his
customers. Thus cost of sales was actually borne by the customer, and they
loved it. I can't recall a single customer complaining to him because their
stuff just kept on working without trouble.

I recommend that you spend some time studying Lisp, both the language
(actually a family of dialects, not a language) and its history. Partly
because ideas from Lisp keep finding their way into new releases of
Java, but mostly for the history. Note that Guy Steele also wrote the
book on Common Lisp, so he was intimately familiar with both. Java is
interesting for what it borrowed and also for what it left out.

 

[Jim Janney]

That is somewhat true.

Java is primarily used in business programming. You need millions
of Java programmers and that means that you will get some very good,
a lot of acceptable and some complete hopeless. And the type
of applications are often semi-important (no one will die if the
application does not work but some one may lose money if the
application does not work). In that context it is important that
Java code written by mediocre programmers actually work. So the
Java language is kept reasonable simple, framework are often
pretty strict and there is a lot of emphasis on following
all the conventions. Maybe a bit boring. Bit usually it works.

I was simplifying, of course, but yes: those are the very qualities that
have led to the success of Java in business programming. Not a niche
that I think anyone expected it to find, but in hindsight it makes
sense.

 

[Arne Vajhøj]

That had better be a strength of every third-party library in every language
for every platform, hm?

You just made a reply to first half of the sentence without including
the second half.

Whoever told you that half sentences in English would make sense
was wrong.

Code conventions and a library's utility are weakly correlated, I venture.

There are certainly more important factors.

But following convention do make the library easier to use.

I mean, perhaps it does, I just don't see its help to code quality. In
decades of working on other peoples' code, the most "individual" code has
been the most bug-riddled and difficult to maintain.

That is the flip side of his point.

There certainly is a lot of room for style in Java coding, but if you follow
good engineering practices rigidly there will tend to be commonalities with
so-called "conventions". You're going to write complete, thorough, informative
Javadoc comments as a matter of habit. You're going to use get/set methods.
You're going to use a lot of read-only, final, immutable types. You will tend
to use generics. You're going to indent consistently, if not conventionally.
You're going to use version control even for solo projects where you are
producer, director, cinematographer, stars and extras. Every input will be
checked for boundary conditions. You probably even will have written various
sorts of useful tests. And this is true whether you're using Java or the useful
idioms and practices of some other platform.

Some conventions are good in some objective sense.

But other conventions are only good because everybody else
uses them.

Arne

 

[Arne Vajhøj]

I was simplifying, of course, but yes: those are the very qualities that
have led to the success of Java in business programming. Not a niche
that I think anyone expected it to find, but in hindsight it makes
sense.

And hard to call business programming a niche.

I would expect it to be the majority of programming.

Arne

 

[Jim Janney]

And hard to call business programming a niche.

I would expect it to be the majority of programming.

In terms of lines of code and total programmer-hours expended, that may
well be true. Call it a large niche

 

[Arved Sandstrom]

In terms of lines of code and total programmer-hours expended, that may
well be true. Call it a large niche

Call it a huge niche, "business" programming. If you're writing code to
solve a problem for a business, you're doing business programming. It
may be anything from doing asset management for an airport, to analyzing
traffic patterns in a shopping centre, to coding new laws and
regulations into a program that needs to be aware of those laws and
regulations. Only a small percentage of business software explicitly
deals with money, but *all* business software deals with money at least
indirectly, because the operations of a business (which includes
governments) are supported.

I'd say 90 percent of programming is business programming.

AHS