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 class
es/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”