• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Tim Cooke
  • Campbell Ritchie
  • Ron McLeod
  • Liutauras Vilda
  • Jeanne Boyarsky
Sheriffs:
  • Junilu Lacar
  • Rob Spoor
  • Paul Clapham
Saloon Keepers:
  • Tim Holloway
  • Tim Moores
  • Jesse Silverman
  • Stephan van Hulst
  • Carey Brown
Bartenders:
  • Al Hobbs
  • Piet Souris
  • Frits Walraven

Java w/OOP principles.. (theory?)

 
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
author
Posts: 3252
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
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
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks,
Thats exactly the type of answer I was hoping for..
 
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 2596
Android Firefox Browser Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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).]
 
Ranch Hand
Posts: 69
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic