Question about inheritance

[ghanoz2480]

I read a tutorial about inheritance (http://java.sun.com/docs/books/
tutorial/java/IandI/subclasses.html) and i want to ask why when we can
declare a field in the subclass with the same name as the one in the
superclass, it is not recommended?
Anybody can help explained about it? Or have a "good resource" to
share me about that question? Thank you.

 

[Arne Vajhøj]

I read a tutorial about inheritance (http://java.sun.com/docs/books/
tutorial/java/IandI/subclasses.html) and i want to ask why when we can
declare a field in the subclass with the same name as the one in the
superclass, it is not recommended?
Anybody can help explained about it? Or have a "good resource" to
share me about that question?

In general it is messy to use two distinct "items" with the
same name in the same part of the code. It makes the code
harder to read.

I think that is reason enough to avoid it. There may be other
more specific reasons as well, but I can not think of any
right now.

Arne

 

[Eric Sosman]

I read a tutorial about inheritance (http://java.sun.com/docs/books/
tutorial/java/IandI/subclasses.html) and i want to ask why when we can
declare a field in the subclass with the same name as the one in the
superclass, it is not recommended?
Anybody can help explained about it? Or have a "good resource" to
share me about that question? Thank you.

It is normal for a subclass to override a superclass'
method by providing a method of its own with the same name
and parameter list, so that the subclass can specialize its
behavior. For example, it is normal to override Object's
toString() method so that a subclass can provide a String
representation that is meaningful. Specializing behavior
by overriding methods is one of the main purposes of class
inheritance.

Data fields are a little different. Usually they record
the state of an object, while the methods provide behavior.
Usually, the fact that a superclass has been extended by a
subclass does not affect the state of an instance when it
is viewed in its superclass role. JButton is a subclass of
JComponent, so a JButton instance "is a" JComponent instance.
But every JComponent maintains state that does not depend on
whether the JComponent is free-standing, or is a JButton, or
is a JList. The data fields "belonging" to its JComponent
role are maintained the same way regardless of subclassing.

The Java language reflects these two purposes by treating
methods and fields differently. If a subclass overrides a
superclass' method, all calls to that method name execute the
subclass' version -- even calls made from the superclass' own
code invoke the subclass' overriding method. But data fields
do not share this behavior: When the superclass' code refers
to a field named myField, it always uses the superclass' own
myField even if the subclass also has a field named myField.
Methods can be overridden, data fields cannot.

Since methods can be overridden, it is normal to re-use
the same name to refer to the superclass' method and to the
subclass' method that overrides it: Object has toString() and
Double has toString() and AbstractList has toString() and so
it goes. But since data fields cannot be overridden, the only
result of re-using the same name for an entirely different
field is confusion. It is not an override, but using the same
name makes it *look* like an override, and it is seldom a good
idea for code to look like something it actually isn't.

 

[Lew]

It is normal for a subclass to override a superclass'
method by providing a method of its own with the same name
and parameter list, so that the subclass can specialize its
behavior. For example, it is normal to override Object's
toString() method so that a subclass can provide a String
representation that is meaningful. Specializing behavior
by overriding methods is one of the main purposes of class
inheritance.

Data fields are a little different. Usually they record
the state of an object, while the methods provide behavior.
Usually, the fact that a superclass has been extended by a
subclass does not affect the state of an instance when it
is viewed in its superclass role. JButton is a subclass of
JComponent, so a JButton instance "is a" JComponent instance.
But every JComponent maintains state that does not depend on
whether the JComponent is free-standing, or is a JButton, or
is a JList. The data fields "belonging" to its JComponent
role are maintained the same way regardless of subclassing.

The Java language reflects these two purposes by treating
methods and fields differently. If a subclass overrides a
superclass' method, all calls to that method name execute the
subclass' version -- even calls made from the superclass' own
code invoke the subclass' overriding method. But data fields
do not share this behavior: When the superclass' code refers
to a field named myField, it always uses the superclass' own
myField even if the subclass also has a field named myField.
Methods can be overridden, data fields cannot.

Since methods can be overridden, it is normal to re-use
the same name to refer to the superclass' method and to the
subclass' method that overrides it: Object has toString() and
Double has toString() and AbstractList has toString() and so
it goes. But since data fields cannot be overridden, the only
result of re-using the same name for an entirely different
field is confusion. It is not an override, but using the same
name makes it *look* like an override, and it is seldom a good
idea for code to look like something it actually isn't.

Study overrides, overloads, shadowing, hiding and obscuring in the Java
Language Specification (JLS).

 

[Tom Anderson]

I read a tutorial about inheritance (http://java.sun.com/docs/books/
tutorial/java/IandI/subclasses.html) and i want to ask why when we can
declare a field in the subclass with the same name as the one in the
superclass, it is not recommended?

Because it could be confusing to people reading the code. That's the only
reason.

If you have a class:

public abstract class Base {
private int size;

public int getSize() {
return size;
}
}

And a child class:

public class Child extends Base {
private int size;

// imagine lots and lots of code here

public void setValue(Collection coll) {
// do some stuff with coll
this.size = coll.size();
}
}

Then if someone who didn't know both classes well looked at the setValue
method, they might think that the assignment to size would be reflected in
a different value of getSize(), which would not be the case.

tom

 

[Roedy Green]

tutorial/java/IandI/subclasses.html) and i want to ask why when we can
declare a field in the subclass with the same name as the one in the
superclass, it is not recommended?

It just causes confusion. Most programmers simply avoid doing it, so
when they encounter some dork's code who has, the code is unfamiliar,
and they may have to study up to figure out what it does.

see http://mindprod.com/jgloss/gotchas.html#SHADOW

to understand shadowing, (the official term for it).
--
Roedy Green Canadian Mind Products
http://mindprod.com

"If people become accustomed to lying, they will unconsciously commit every possible wrong deed. Before they can act wickedly, they must lie, and once they begin to lie they will act wickedly without concern."
~ Gautama Buddha

 

[Roedy Green]

Because it could be confusing to people reading the code. That's the only
reason.

You would confuse YOURSELF too. It is calling two of your sons Jim.
--
Roedy Green Canadian Mind Products
http://mindprod.com

"If people become accustomed to lying, they will unconsciously commit every possible wrong deed. Before they can act wickedly, they must lie, and once they begin to lie they will act wickedly without concern."
~ Gautama Buddha

 

[Lew]

I read a tutorial about inheritance (http://java.sun.com/docs/books/
tutorial/java/IandI/subclasses.html) and i [sic] want to ask why when we can
declare a field in the subclass with the same name as the one in the
superclass, it is not recommended?

Because it could be confusing to people reading the code. That's the
only reason.

If fields are of higher visibility than private, then there is an additional
consideration. The "more local" or "more inner" declaration shadows or hides
the "less local" or "less inner" declaration, requiring additional prefixes to
the shadowed identifier if one actually intends to use it.

There is also obscuring, which is a matter of confusion and not of syntax.

These terms, "shadowing", "hiding" and "obscuring", have specific technical
definitions in the JLS.

 

[Mike Schilling]

On Sun, 24 May 2009 11:59:50 +0100, Tom Anderson
who
said :


You would confuse YOURSELF too. It is calling two of your sons Jim.

You do realize that Lous XVI and Louis XVIII of France were brothers.

 

[Lew]

Or George, if your last name were Foreman.

You do realize that Lous XVI and Louis XVIII of France were brothers.

Louis XVI was christened Louis-Auguste de France. Louis XVIII was christened
Louis Stanislas Xavier de France. Their names weren't quite the same.

 

[Eric Sosman]

You would confuse YOURSELF too. It is calling two of your sons Jim.

George Foreman's five sons are named George, George,
George, George, and George. Fortunately, they have nicknames.

 

[Tom Anderson]

I read a tutorial about inheritance (http://java.sun.com/docs/books/
tutorial/java/IandI/subclasses.html) and i [sic] want to ask why when we
can declare a field in the subclass with the same name as the one in the
superclass, it is not recommended?

Because it could be confusing to people reading the code. That's the only
reason.

If fields are of higher visibility than private, then there is an additional
consideration. The "more local" or "more inner" declaration shadows or hides
the "less local" or "less inner" declaration, requiring additional prefixes
to the shadowed identifier if one actually intends to use it.

Doh. For some reason, i read the OP's question as only referring to
*private* fields in the superclass. Good point.

tom

 

[Tom Anderson]

George Foreman's five sons are named George, George,
George, George, and George. Fortunately, they have nicknames.

Ironically, his grill doesn't.

tom

 

[Mike Schilling]

George Foreman's five sons are named George, George,
George, George, and George. Fortunately, they have nicknames.

Yeah, they're all nicknamed "Georgie".

Seriously, there's a story behind it. Foreman found out, as a teenager,
that he was the result of an affair his mother had had with a neighbor, and
the man he'd thought of as his father knew that, which is why he'd always
been distant. He wanted to be sure his sons knew that their father thought
of them as his, which is why they're evey one of them George Junior.

 

[Lew]

But it's still true that Charles X used to introduce himself by saying "Hi.
I'm Charles, this is my brother Louis, and this is my other brother Louis."

That is an extremely interesting bit of historical trivia. Thank you.

I am reminded of the Bob Newhart show of several years ago. ("This is my
brother Darryl, and my other brother Darryl.")

 

[Mike Schilling]

That is an extremely interesting bit of historical trivia. Thank you.

I am reminded of the Bob Newhart show of several years ago. ("This
is my brother Darryl, and my other brother Darryl.")

Really? That never occurred to me

 

[charlesbos73]

Study overrides, overloads, shadowing, hiding and obscuring in the Java
Language Specification (JLS).

Another hyper-constructive one-liner from Lew focusing
on the bigger picture.

Amazing open-mindedness.

Actually instead of becoming a JLS nazi, I'd recommend
the OP to study the meaning of inheritance in the bigger
OO picture.

Learning to become a JLS nazi apparently may hinder
people from seeing the bigger picture and from staying
polite (you've been particularly rude to a regular poster
in here recently, saying that you wouldn't be reading his
post should you have the opportunity to opt-him-out or
something like that).

Anyway, to the OP...

I'm currently working on a wonderfully "OO designed"
application and the translation to Java is a breeze.

Zero instance of the "abstract" keyword.
Zero instance of the "protected" keyword.
"extends" is only ever applied to interface.

And there's *much* *much* more heresy to JLS nazis than
that. A complex subpart has been implemented using *only*
immutable objects. Not a single setter. "OO over
immutable objects" (heresy uh !?).

The DB is an OO DB (heresy, I tell you!).

When will I fail? When will people doing OOP in
languages not allowing concrete implementation fail?

But, more importantly, how relevant become such issues
when one is doing OOA/OOD -> OOP translation without ever
relying on implementation inheritance? (I'm not saying
the issues don't exist when extending [Java] interfaces,
but having all these fields final by default sure helps mitigate
many concerns

How I miss my lurking days in c.l.j.p. when JLS nazis
where actually clueful about the bigger picture (I think
particularly about "T. M.", an engineer of the
Java IBM VMs). He was not only pointing to the
JLS like a JLS nazi but he was also nearly always
explaining why it was probably a waste of time to
focus on such things.

And all this knowledge is accessible thanks to, say,
groups.google.com.

Much more useful than your "read the JLS" one-liners
that could be tagged as "the author requested this post
not to be archived".

T.M. was one heck of a JLS nazi (and all around JVM
expert) and he definitely could see the bigger picture.

You're posts just lack open mindedness.

I'd recommend reading section x.y.z of the JLS if
it could help you "free your procedural SQL mind",
but sadly it takes more than searching and memorizing
abilities.

 

[Seamus MacRae]

"Polite"? What sort of politeness is it where you call people names,
like "JLS nazi", accuse them of "lacking open-mindedness", and treat
their posts with sarcasm and derision?

Whatever you might say about Lew's posts, I've yet to see him go the ad
hominem route

I have seen it. Several times versus myself and several other people in
the big Lisp thread, and he twice called Giovanni Azua a liar in another
recent thread.

You hardly seem to be demonstrating behavior that qualifies you to
characterize someone else as "polite" or not.

Powers of observation and knowledge of the rules of polite society
suffice. He may qualify, then, if his own violations of said rules are
intentional rather than a result of ignorance.

The rest of your post just seems like so much trolling and straw-man
posturing, not at all relevant to the original question, so no need to
comment on the technical details (such as they are).

Perhaps the phrase "turnabout is fair play" applies here. "Lew" has made
numerous recent posts that can be characterized as "trolling and
straw-man posturing"; that someone might react by eventually doing
likewise to him seems unsurprising.

 

[Lew]

In point of fact, it is extremely helpful to read the JLS. The cited sections
in particular clear up all kinds of questions about the OP's issue. There's
nothing quite like going to the source for clarity.

 

[Joshua Cranmer]

Actually instead of becoming a JLS nazi, I'd recommend
the OP to study the meaning of inheritance in the bigger
OO picture.

What's wrong with citing from the JLS or pointing someone to read there?
The language is astonishingly approachable--try reading the ISO C++
specification sometime. It is also 100% freely available, as well as
being the complete authority on Java. What the JLS says is always
correct (modulo any errata that accumulates).

Besides, resolution of names is an area where what the compiler thinks
you're trying to do and what you think you're trying to do are not
necessarily the same thing.

And there's *much* *much* more heresy to JLS nazis than
that.

OP asked about why shadowing is not recommended, not a diatribe on the
perceived personal opinions of a class of people. FWIW, I haven't
considered any of what you mention to be heretical, and I'm as much a
"JLS nazi" as Lew.

And all this knowledge is accessible thanks to, say,
groups.google.com.

Usenet is the more accurate term.