Please can anybody tell me, when actually we need to use PROTECTED access specifier in real life application. I will really appreciate if you can expain me giving example, where declaring a class as protected is the only option left.
I don't think there is ever a case where "protected" is the only possible choice. You can always declare the thing "public" and achieve the same result, in terms of functionality.
However, there are plenty of cases where "protected" is a good idea, to help maintenance and understandability of your code.
If you are thinking specifically of "protected" as the access specifier of a class, then it is most likely to be used as the access specifier of an inner class. It then says that the inner class, while inaccessible to out-of-package classes in general, is accessible to classes that are subclasses of the main class.
Betty Rubble? Well, I would go with Betty... but I'd be thinking of Wilma.
If you say something is "protected" it means that subclasses should have access to it.
This is what you would do if you define a particular class in one package, and then subclass it in another. In such a case, the default package-level access would be too restrictive, and "public" access would blow any encapsulation you're trying to do out of the water. So, "protected" is the way to go.
- Rick S.
Joined: Sep 12, 2005
Thanks for that.
But still not very much convinced, so it will you can ellaborate it more and i will really appreciate if you can expalin giving short example. Because i think if it is there, there has to be some good reason and a need.
Note that the two routines are labelled as "protected," meaning that they can only be called by routines in the same package or in a subclass. That makes sense. It is probably not meaningful for your servlet to be called other than to process an HTTP request. If it is meaningful to invoke your doPost() routine otherwise, then your system design probably needs some refactoring, perhaps to split out a chunk of the common code into a Java bean.