Java w/OOP principles.. (theory?)

[steven brown]

Hi,
A couple questions:
Why does Java enforce that a subclass can not make overriden methods any more private than its superclass' method?
also,
Why does the compiler not allow overriden methods where a subclass throws exceptions not found in the superclass throws clause?

[Peter den Haan]

Originally posted by steven brown:
Why does Java enforce that a subclass can not make overriden methods any more private than its superclass' method?

Because of the substitution rule. A subclass "IS-A" specialisation of its superclass, implying that wherever you can use an instance of the superclass, you must be able to use an instance of the subclass. Now if any of the methods in the subclass would be more private, you would no longer be able to substitute the subclass for the superclass in situations where this method is being called.

Why does the compiler not allow overriden methods where a subclass throws exceptions not found in the superclass throws clause?

For the very same reason. Code that calls the superclass method expects a certain list of exceptions. If the subclass would throw additional (checked)exceptions, it would no longer be substitutable.
For anyone reading this, I have a question along similar lines. When overridding a method in the subclass, it is not possible to change the return type. While I can understand that you cannot widen the return type - that would fall foul of the substitution rule - I do not understand why it is not possible to narrow the return type. For instance, why can't I write

public class MyClass implements Cloneable {
   public MyClass clone() {
      try {
         return (MyClass)super.clone();
      } catch (CloneNotSupportedException e) {
         // can't be - something horrible is happening
         throw new Error(e.getMessage());
      }
   }
}

Why does the JLS prohibit this, forcing me to return an Object?
- Peter

[This message has been edited by Peter den Haan (edited September 20, 2001).]

[steven brown]

Thanks,
Thats exactly the type of answer I was hoping for..

[Jim Yingst]

For Peter's question- I don't know really. I've wondered the same thing. My best guess is that it's done for simplicity. For folks using this class, it's easier to understand the rule that all overriding methods have the same return type as the overridden method, period, rather than having to check which version of a method is being used - in order to determine whether to insert a cast or not, for example. Also, we can replace "people using this class" with "people coding a JVM which is responsible for loading this class and verifying it before it is allowed to execute" - this minor simplification may make their lives a bit easier.
Why not create a new method name like cloneMyClass() which returns type MyClass? Any code outside this class which will interact with it will fall in one of two categories: (1) code written before (or without knowledge of) MyClass, which will can only invoke clone() by assuming it returns an Object, so such code couldn't benefit from your returning a MyClass anyway, or (2) code written after MyClass, which can use the cloneMyClass() method instead to get exactly the type of cloning that is desired.
I hope that made some sense - I'm just making this stuff up as I go, after all.

[Manish Hatwalne]

Originally posted by Peter den Haan:
For anyone reading this, I have a question along similar lines. When overridding a method in the subclass, it is not possible to change the return type. While I can understand that you cannot widen the return type - that would fall foul of the substitution rule - I do not understand why it is not possible to narrow the return type. For instance, why can't I write ....
Why does the JLS prohibit this, forcing me to return an Object?

If I am not mistaken, in OOPs terminology this feature of an OO language is termed as covariant return type which is based on same substitution (by subtype) principle.
This feature is not supported in java,despite of repeated requests and bug submission (AFAIK). This has been a hot topic of discussion at java.sun.com for quite some time now.
See this 1.
and this too (bug).
C++ as a language supports it in its standards, but not all compilers allow you to do this. (including M$ VC++ 6.0 compiler)
- Manish


[This message has been edited by Manish Hatwalne (edited September 23, 2001).]

[shashank shah]

Besides clone() and Cloneable are already messed-up. Needing u to call super.clone() to create explicite chaining and Clonable dictating how Object's clone() method will work and creating objects w/o calling constructors etc.
-Shashank