Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Cloud/Virtualization forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Use of Protected access specifier in real-life application

 
Megha Jain
Ranch Hand
Posts: 30
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

Waiting ............
 
Peter Chase
Ranch Hand
Posts: 1970
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Rick Stabile
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Megha Jain
Ranch Hand
Posts: 30
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

Thanks
 
Marco Vanoli
Ranch Hand
Posts: 99
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
doGet and doPost of HttpServlet are protected.


This is from "just java 2":


protected void doGet(HttpServletRequest req, HttpServletResponse resp)

throws javax.servlet.ServletException, java.io.IOException;

You call methods on the HttpServletRequest argument to find out what the browser is asking for exactly. There's a method you call to get a PrintWriter from the HttpServletResponse, and you write your resulting plain text, HTML, image file, audio file, or Javascript using it. What you write gets sent back to the browser. It's as simple as that.

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.
 
Megha Jain
Ranch Hand
Posts: 30
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks everybody.......... i got it.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic