Java – Overriding – Access to Members with Reference Reassignment

javamethodsreference

I have recently been moving through a couple of books in order to teach myself Java and have, fortunately, mostly due to luck, encountered very few difficulties. That has just changed.

I read a section on the following under inheritance and the whole superclass subclass setup

When a new superclass object is created, it is, like all objects, assigned a reference (superReference in this example)
If a new subclass object (with the defining subclass extending the superclass) is created, and then the superReference reference is set to refer to that instead of the original object, it is my understanding that, since the reference is made for a superclass, only members defined by the superclass may be accessed from the subclass.

First – is this correct?

Second:
If I am overriding a method and therefore have one in the super and one in the sub, and I create a superclass object and then assign its reference, as I did above, to a subclass object, by the principle called something like Dynamic Method Dispatch, a called overridden method should default to accessing the subclass method right?

Well, my question is:

If a reference to a superclass-object is retooled for a subclass-object and will deny direct object.member access to subclass-defined members, only supporting superclass-defined members, how can, if a superclass reference is retooled for a subclass object, an overridden method apply to the subclass-object if access is limited by the superclass-originated-reference

Best Answer

If you look at the Java Language Specification (http://docs.oracle.com/javase/specs/) you will find a distinction between the static type and the dynamic type of object references.

The static type of any reference refers to the type declared in your program at development time.

The dynamic type of the reference refers to the type of object which is actually stored at the reference address at runtime.

So if you have a simple hierarchy, where A is the superclass and B is a subclass of A.

class A {
  public String a = "super";
  void m() {...}
}

class B extends A {
  public String a = "sub";
  @Override
  void m() {...}
}

A refA = new A();
A refB = new B();
B refB2 = new B();
refA.m();
refB.m();
System.out.println(refA.a);
System.out.println(refB.a);
System.out.println(refB2.a);

For example, refB's static type is A but its dynamic type is B. What does this imply at runtime?

Instance variables are statically bound, i.e. you can only access the instance variables of the static type, so the first two println() statements will print "super", since A is the static type of refA and refB. The last println() statement will in contrast print "sub", because in this case B is the static type.
Methods are dynamically bound, i.e. the invoked method is first searched in the dynamic type of the reference and if it isn't found, the class hierarchy is traversed up until a definition of the overriden method is found (this mechanism is called dynamic dispatch). This means that in case refA.m() method void m() of A is invoked and in case refB.m(), void m() of B is invoked.

Related Solutions

Java Methods – Naming Methods with Different Return Types

Why do you need to extend this class? And why do you need to name your own method the same as showDialog?

In reality your method does something entirely different than what showDialog does. A better name for your method would be showDialogAtLocationAndReturnSelectedFile as your method does more or less these things. Naming it showDialog will only confuse your code users.

Also, without knowing anything else, I'd say you're trying to shove too much in a single method. How do you react on a cancel press? How about an error? Do you return null? If so, you're forcing the user of the code to check the return value yet again. This has the potential of being just another "Leaky Abstraction", and Java APIs already have enough of these.

An important part of API design is making sure that the name of a function/class/method matches what it really does. And that is why in JFileChooser the method's name is showDialog. It just shows the dialog. It doesn't open the file for reading, it doesn't perform a check whether the filename is valid, and honestly, why would it? The user of the code just asked the class to show the dialog.

The creator of Ruby calls this the 'Principle of Least Surprise'*, and while I don't really know Ruby, this is a great line to learn from. Your code should be in the service of its user, and a part of this service is embedding the contract of the method/class in its name.

You might think you're not designing an API, but I doubt you work alone: there's probably someone else in the team, and they will appreciate this. Also, I heartily recommend this lecture on API Design: How To Design A Good API and Why it Matters. It was presented to Googlers by a Java designer, so it kinda matters.

Maybe this is more than you asked for, but I feel you seem to be somewhat missing the point of naming methods.

UPDATE: * I seem to be mistaken, the creator of Ruby has actually stated that he designed Ruby with the "Principle of Least Astonishment", not "Principle of Least Surprise". In any case, what I said still holds.

Java Inheritance – Is Code from Superclass Copied or Referred to by Subclass?

Option 2.

The bytecode is referenced dynamically at runtime: this is why, for example, LinkageErrors occur.

For example, assume you compile two classes:

public class Parent {
  public void doSomething(String x) { ... }
}

public class Child extends Parent {
  @Override
  public void doSomething(String x) {
    super.doSomething(x);
    ...
  }
}

Now modify and recompile the parent class without modifying or recompiling the child class:

public class Parent {
  public void doSomething(Collection<?> x) { ... }
}

Finally, run a program that uses the child class. You will receive a NoSuchMethodError:

Thrown if an application tries to call a specified method of a class (either static or instance), and that class no longer has a definition of that method.

Normally, this error is caught by the compiler; this error can only occur at run time if the definition of a class has incompatibly changed.

Best Answer

Related Solutions

Java Methods – Naming Methods with Different Return Types

Java Inheritance – Is Code from Superclass Copied or Referred to by Subclass?

Related Topic