3

Please consider the following situation:

class A{

    private int num = 10;

    public int getNum(){ return num; }

    public void setNum(int num){ this.num = num; }

}


class B extends A{

    private int num;

    public B(){

        num = getNum();

    }

}

In Java, a way for a subclass to have access to the superclass' private members, without declaring them protected (since that will expose them to the entire package), could be to use the superclass' getters and setters. Not only in the subclass' constructor, but anywhere needed.

Is this something used by people? Common? Have you ever seen this?

Aviv Cohn
  • 15,543
  • 25
  • 68
  • 131
  • 3
    It's a valid thing to do, although I don't see the point of the instance variable `B.num` -- you can just use getNum() where needed. – GriffeyDog Apr 15 '14 at 16:01
  • you can use method of super class where private variable used. so In short, you can use `private` variable through `public/protected` method of super class.i.e. as here you use `getNum()` method that return value of `num`. – bNd Apr 15 '14 at 16:03
  • You wrote "without declaring them protected (since that will expose them to the entire package)". Thats wrong. "protected" means only accessible to inheriting classes. This seems to be what you are looking for. – blafasel Apr 15 '14 at 16:05
  • 1
    Why are you repeating the `num` field in the subclass? B already has a field called `num` (accessible by `getNum()` and `setNum()`) inherited from A. Why did you repeat it in B? (Note that the `num` in B is both inaccessible and always 0, given the code as shown.) – Paul Apr 15 '14 at 16:08
  • 1
    @blafasel: no, that's wrong: http://docs.oracle.com/javase/tutorial/java/javaOO/accesscontrol.html – JB Nizet Apr 15 '14 at 16:09
  • @Nizet. Can you please explain the point you made? I am not able to get what part of it is wrong after seeing the link. – bgth Apr 15 '14 at 18:39

2 Answers2

2

Yes, this is a common approach, especially in order to encapsulate the inner working of the super class.

Consider a library class that is meant to be subclassed. When making the instance variables visible to subclasses and someone would have to change the super class and maybe remove the field in a new version it would make that library version incompatible with older versions.

The same holds true for your own classes but it might not be that problematic if you exposed fields to internal subclasses.

Using another variable and calling the getter in the constructor like above, however, would be problematic because you'd also have to override the setter in order to get notifications on changes which adds complexity and code with little to no benefit.

Thomas
  • 87,414
  • 12
  • 119
  • 157
0

Yes. It is common. And preferable to exposing the fields (even if only as protected). A class's encapsulation isn't only for hiding details from code that constructs and uses instances, but also for hiding them from subclasses.

I'd say this is not only common - it is (and should be) the norm. I've written many thousands of classes and dozens of in-house libraries; I haven't made a member field public, protected or package private in years.

Paul
  • 3,009
  • 16
  • 33