Quantcast
Viewing latest article 1
Browse Latest Browse All 12

Why public access level method get overridden in java?

This question is raised with a clarification required to decide when to declare a method protected or public during class design of a package.

My point is, if one needs to override a method of a SuperClass then make that method access level as package private or protected in SuperClass but do not give access level public, and then SubClass inherit SuperClass to override that method.

if public access level method is also overridden in SubClass then public access level method has also become an implementation dependent method in every new SubClass designed, which breaks Encapsulation. Because user using public level access method addNotify(), should know that it’s implementation is different in awt.Component/ awt.Checkbox/awt.Button class, which means hiding of implementation details not ensured here. In addition, abstract class is supposed to be discovered and designed to have only common implementations of its concrete subclass methods, bas per definition of abstraction, But it is pretty strange to see that abstract class Component{} breaks this definition.

With the access level given to this method public void addNotify() {}, Without knowing the meaning or significance of this method, I would like to ask,

Does it become difficult to decide the access level of a method during class design to be either public or protected?

Because I would like to say that at design time any method will be public in SuperClass only when below 2 reasons are satisfied:

1) There must not be a need to override this method in SubClass in/out of package, if one tries to override SuperClass.

2) Based on the signature of any public level method it must be safe after making a decision that this method can be publicly available so that means this method should not be implementation dependent in any new SubClass in/out of package. signature in the sense that, i made my below DList class available to perform sequential update of DList in O(n) time, so no SubClass must override prevNode() method of DList class. This is risky!!! Because prev/next pointers can be manipulated here with bad coding. LSK principle will become safe.

   package DList;/* DList.java */ 
   public class DList {
    ......
      public DListNode prevNode(DListNode node) { /* check this signature*/
        if(node.prev != this.sentinel){
            return node.prev;
        }else{
            return null;
        }
      }
    .......
    }
    /* DListNode.java */
    package List;
    public class DListNode {
       public Object item; /* check this */
       protected DListNode prev;
       protected DListNode next;

      DListNode(Object i, DListNode p, DListNode n) {/* check this signature*/
        this.item = i;
        this.prev = p;
        this.next = n;
      }
    }

So,

With the experience of java code written, it looks easy for me to decide the one of the two possible access levels of all the classes/interface design within a package.

it looks easy to decide while introducing signature of new methods,
whether a method should have access level private
whether a method should have access level package private

If i understand the below question, It would become easy to decide when a method be protected or public.
1) Why java allows to override public access level methods? Because it is difficult for me to decide when to make my method protected, despite i know that public is more visible than protected among packages. One has to foresee the cost/consequence of introducing a new inheritance relation before giving protected access level to the method of your current design of class.

2) Can i know the proper resource to learn when a method can be protected?

Note: I am a Java beginner who currently understands abstraction/encapsulation/inheritance/polymorphism and about to learn “package and access specifiers”


Viewing latest article 1
Browse Latest Browse All 12

Trending Articles