GeeCON Prague 2014*
The moose likes Beginning Java and the fly likes Private versus Protected: Much Ado About Nothing? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Private versus Protected: Much Ado About Nothing?" Watch "Private versus Protected: Much Ado About Nothing?" New topic
Author

Private versus Protected: Much Ado About Nothing?

Robin Lane
Ranch Hand

Joined: Apr 30, 2008
Posts: 76
My textbook made a big deal out of making certain data private and then available (but not changeable) via public methods. However, my instructor (and a few past classmates with programming experience) seemed to prefer the protected access modifier.

I can understand why it would be a good idea to hide certain data, especially if your are producing commercial programs. My question is this: Is protected (seemingly) preferred because it is easier to code around? After all, it does seem to take a little more thought, designing, and planning to use the private access modifier.


Disclaimer: The author of this post makes no claims, implied or otherwise, as to her ability to understand anything but the simplest of answers. Further, the author of this post has no programming background whatsoever and has taken one Java Programming class which was 9 weeks long. She does want to learn, so please teach patiently.
marc weber
Sheriff

Joined: Aug 31, 2004
Posts: 11343

Originally posted by Robin Lane:
...my instructor (and a few past classmates with programming experience) seemed to prefer the protected access modifier...

I don't think this is a question with a general, all-purpose answer, because it depends on the context. I think you should ask them why they seem to prefer protected. It might be a good discussion.

Of course, a protected member is available to subclasses. This might seem "easier to code around" because a subclass can access a protected field directly, rather than using a method to access a private field in the superclass, but that might be defeating the purpose.

In considering this, I think you need to go back to the question of why these fields are restricted in the first place, and how inheritance is being used in these cases (which might also prompt an inheritance vs. composition debate). Is there a risk in allowing direct access from a subclass? Or is this a perfectly acceptable approach for the situation?
[ June 22, 2008: Message edited by: marc weber ]

"We're kind of on the level of crossword puzzle writers... And no one ever goes to them and gives them an award." ~Joe Strummer
sscce.org
Robin Lane
Ranch Hand

Joined: Apr 30, 2008
Posts: 76
Originally posted by marc weber:

I don't think this is a question with a general, all-purpose answer, because it depends on the context. I think you should ask them why they seem to prefer protected. It might be a good discussion.


I would love to know, but my classes are online classes. Sometimes, a question doesn't get answered. Well... frequently that type of question goes unanswered. Most of my classmates are working full-time jobs and raising families, as well as taking classes. They simply do what is required, because that is all they have time for. That's why I was asking here. I was hoping for some insight, because I'm so naive about programming.

Here's an example, though. We did a project that was built over four weeks. It was an inventory program, and we could customize it some (type of product, information to gather, GUI appearance) as long as we satisfied the requirements. In my project, I was using the private access modifier, but when my instructor sent me some suggested code, all of his attributes were protected.

A previous classmate mentioned that he preferred the protected access modifier, but the reason he gave made it sound like it was more a matter of convenience. Yet, all of the examples in my textbook made data private and methods public to allow access to the private data. This got me wondering under what circumstances did it matter beyond personal taste.
Marilyn de Queiroz
Sheriff

Joined: Jul 22, 2000
Posts: 9046
    
  10
One of the big advantages of making the variables private and accessing them with public methods is encapsulation. Perhaps you want to do some calculation before returning that variable ...

For example, rather than


you may want to do something like


If "size" is private, the change is easy to make and invisible to the caller of the getSize() method. If "size" is protected, you may have problems because someone will call size directly and may get a negative number. These kinds of bugs can be difficult to track down, especially in a large application. This is only one example of why I believe encapsulation is an essential part of OO development.


JavaBeginnersFaq
"Yesterday is history, tomorrow is a mystery, and today is a gift; that's why they call it the present." Eleanor Roosevelt
Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 14194
    
  20

The main reason for hiding data in classes as much as possible is that when the public interface of a class (the publically accessible methods and variables) is as smaller, then the class has less coupling to the outside world and that will help to heep your program less complicated.

So, I would always hide as much as possible and prefer private over protected. In my opinion, there needs to be a special reason why you would make something any more accessible than private. Making things protected because you might someday want to extend the class and access a variable or method from the subclass is not a good reason. So I don't agree with what your teacher does.

Note that protected variables and methods are not only accessible to subclasses, but also to all other classes in the same package.


Java Beginners FAQ - JavaRanch SCJP FAQ - The Java Tutorial - Java SE 8 API documentation
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
When I have to maintain old code, one of the first things I do is making all protected fields (if there are any) private. That typically removes a lot of complexity and makes it ways easier to understand the code.


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 39084
    
  23
Shame that you can't discuss these questions with people face to face.

I think I agree about making fields private. Consider "protected" not so much as a way of restricting access, but a way of permitting access, both to subclasses and to the other classes in the same package. So I would prefer all the fields private (except constants). As Marilyn has demonstrated, you can permit "read-only" access to those fields by providing only public "get" methods.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 39084
    
  23
Originally posted by Robin Lane:
After all, it does seem to take a little more thought, designing, and planning to use the private access modifier.
If you want good code, it takes a lot of thought design and planning, regardless. Programming is a difficult activity.
marc weber
Sheriff

Joined: Aug 31, 2004
Posts: 11343

Originally posted by Campbell Ritchie:
... Consider "protected" not so much as a way of restricting access, but a way of permitting access...

That's a good way to look at it. The name "protected" is a little misleading, because there's not much protection there. Think of it as "almost public."

Avoiding the "private" modifier because it's inconvenient to code around is a poor excuse. You would be better off using no modifier (default access) rather than going in the other direction of using "protected."
Robin Lane
Ranch Hand

Joined: Apr 30, 2008
Posts: 76
This discussion is just one more example of why I love this site! I got wonderful feedback and top-notch advice in posts that make sense in both a practical and professional manner.

The response I got is also proof that Dr. Barry Burd made a very good decision when he referenced this site in his Java for Dummies book.

You all are the best, and I am so grateful!
 
GeeCON Prague 2014
 
subject: Private versus Protected: Much Ado About Nothing?