why can't we assign weaker privilege in subclass

Question

I have a class which has a method whose access specifier by default is public. Now, I would like to extend this class in a subclass and I want to override this method to hav

Answer 1

I think the short answer is that the compiler writers have set the rules to work this way. LSP has nothing to do with the problem at hand.

The only reason I can think of to have this restriction is that when a subclass derives from an interface, as a client programmer, you expect to be able to call all the accessible methods of the interface from a reference to the derived class.

Just suppose that you could write the code that the OP has shown. If you have a reference to the derived class you should be able to call any public members of the derived class (though there are none in this case). However, pass the reference as a parameter to a method which takes a reference to the base class and the method will expect to call any public or package method, which is foo. This is the LSP that other contributors are looking for!

C++ example:

class Superclass{
public:
virtual void foo(){ cout << "Superclass.foo" << endl; }
};

class Subclass: public Superclass{
virtual void foo(){ cout << "Subclass.foo" << endl; }
};

int main(){
Superclass s1;
s1.foo() // Prints Superclass.foo

Subclass s2;
// s2.foo();  // Error, would not compile

Superclass& s1a=s2; // Reference to Superclass 'pointing' to Subclass

s1a.foo(); // Compiles OK, Prints Subclass.foo()
}

Answer 2

In dynamic method dispatch, call to overridden method is resolved at runtime rather than compile time. It based on the object being referred to at the time of the call...

Now suppose weaker access privilege was allowed and we write the following statement in your code some other class:

Superclass ref=new Subclass();
ref.foo()

Now during runtime, when java comes across the statement ref.foo(), it will have to call foo() of Subclass...but foo() method of subclass is declared as private in your code and private cant be called outside its own class..so now there is a conflict and it would result in runtime exception...

Answer 3

Apart from the obvious problems with using such a constructions(as pointed out by Peter Lawrey in his answer), read about the theory behind it as well: LSP, which means you must be able to substitute the main type with its subclass.

Answer 4

Because you alter the order of access privileges , so you got error

correct order is:==> private to default to protected to public

*in your case you goes default ==> private whenever you goes in wrong order ,it result is error

Right order of access privilege is--

`class SuperClass{
          void foo(){
    System.out.print("SuperClass");
     }
   class SubClass extends{

  //--default to default--//
         void foo(){
  System.out.print("SubClass");
   }
 //--default to protected--//

  protected void foo(){
  System.out.print("SubClass");

 //--default to public //

 public void foo(){
 System.out.print("SubClass");
 }` 

    **you make sure to preserve correct order while overriding **

Answer 5

Constricting the access modifier of a super class method is an invalid override because it's breaking the super-class contract and invalidates the substitution principle i.e. a sub-class object IS-A super-class object as well.

public void doSomething(SuperClass sc) {
  sc.publicMethodInSuperClass();
}

doSomething(new SubClass()); // would break

If this was allowed, the above client code would break because your SubClass doesn't have that method public.

Reference:
Liskov substitution principle

Answer 6

You can't restrict access because you have already allowed more access in the super class. e.g.

SuperClass sc = new SubClass();
sc.foo(); // is package local, not private.

The access of sc is determined by the type of the reference sc not what it references because it is impossible for the compiler to know in all cases what type the object is at run time. For this to be a safe assumption the sub-class must honour the contract given by the parent or it fails to be a valid subclass. This is no different to the parent saying a method is implemented but the sub class saying it is not (or not accessible)

You could work around this by saying you can only access the sub-class method via the parent, not directly. The problem with this is you don't know when a parent might add a method and when you make a method private you do this because you want it to be private, and not accessible another way.

BTW You can still access a private method via reflection which has the side effect that it cause all sort of problems for the JVM. e.g. it has to keep private methods even though it might determine there is no way it can be called normally.

In short, you want code which means what it says, and not have a split personality. It is either package local or it is private not something sort of in between but not really either. This is not such a problem the other way. i.e. if the sub class is public. It just means the sub-class can be used in more places than the parent, just like it can implement more methods.