• 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:
  • Campbell Ritchie
  • Paul Clapham
  • Tim Cooke
  • Jeanne Boyarsky
  • Liutauras Vilda
Sheriffs:
  • Frank Carver
  • Henry Wong
  • Ron McLeod
Saloon Keepers:
  • Tim Moores
  • Frits Walraven
  • Tim Holloway
  • Stephan van Hulst
  • Carey Brown
Bartenders:
  • Al Hobbs
  • Piet Souris
  • Himai Minh

Cannot reduce the visibility of the inherited method from super class

 
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Why cannot reduce the visibility of the inherited method from super class ?

what is the specific reason for above problem.

I am unable to absorb it. Kindly explain.
 
Bartender
Posts: 5167
11
Netbeans IDE Opera Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Simple answer: because the Java Language Specification says so.
http://java.sun.com/docs/books/jls/third_edition/html/classes.html#8.4.8.3
(Scroll down to the end of the section)
The access modifier (ยง6.6) of an overriding or hiding method must provide at least as much access as the overridden or hidden method, or a compile-time error occurs. In more detail:

  • If the overridden or hidden method is public, then the overriding or hiding method must be public; otherwise, a compile-time error occurs.
  • If the overridden or hidden method is protected, then the overriding or hiding method must be protected or public; otherwise, a compile-time error occurs.
  • If the overridden or hidden method has default (package) access, then the overriding or hiding method must not be private; otherwise, a compile-time error occurs.


  • Oh, and welcome to the Ranch!
     
    Bartender
    Posts: 3225
    34
    IntelliJ IDE Oracle Spring Chrome Java
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Hi Surya, Welcome to JavaRanch.

    Its how the language was designed. There are few things in the language which the creators of it would know. But a may-be reason: The Method is owned by the Super class and its not fair if the sub class suppresses it/reduces its visibility. Also in case we use a Super Class reference and try to invoke the overridden version of the method in the Sub class by creating a Sub class instance and assigning it to a Super class reference- this wouldn't be possible as the overridden method is not accessible outside the class declaration.

    Other members might have a better answer

    Update: Darryl was quicker
     
    Bartender
    Posts: 4568
    9
    • Likes 1
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    To expand on what Mohamed said, consider this example:
    There's a principle in object-oriented programming called the "Liskov substitution principle" that says that whenever an instance of a class is required, an instance of any subclass can be used as well. So the code on lines 11/12 above should be valid. We should always be able to assign a B to an A variable. But what happens when we try and call myMethod? It should be OK, because myMethod is public in A, and we've got an A variable. But it's really a B object, so it can't be allowed! We've got an inconsistency. The rule is in place to prevent this.

    Note that increasing the visibility doesn't cause this problem, and so it's allowed.
     
    surya ojha
    Greenhorn
    Posts: 2
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Matthew Brown wrote:To expand on what Mohamed said, consider this example:
    There's a principle in object-oriented programming called the "Liskov substitution principle" that says that whenever an instance of a class is required, an instance of any subclass can be used as well. So the code on lines 11/12 above should be valid. We should always be able to assign a B to an A variable. But what happens when we try and call myMethod? It should be OK, because myMethod is public in A, and we've got an A variable. But it's really a B object, so it can't be allowed! We've got an inconsistency. The rule is in place to prevent this.

    Note that increasing the visibility doesn't cause this problem, and so it's allowed.



    thanks for describing. thanks a lot. I got it. (atleast one reason).
     
    Marshal
    Posts: 76394
    364
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Another way to describe it is that the subclass method is a refinement of the superclass method. A refinement means that in all instances where the refined operation is feasible, the refining operation is feasible. ∀x·fis(superclass(x)) ⇒ fis(subclass(x))

    This is incorporated in the Liskov Substitution Principle.

    That means, if you can do it in the superclass, you must do it in the subclass too, so you mustn't change the subclass method from public to private, or throw new Exceptions or anything. The compiler enforces that as far as possible, but the compiler can't check unchecked Exceptions.
     
    moose poop looks like football shaped elk poop. About the size of this tiny ad:
    the value of filler advertising in 2021
    https://coderanch.com/t/730886/filler-advertising
    reply
      Bookmark Topic Watch Topic
    • New Topic