#134984 - keldon - Thu Jul 19, 2007 12:40 am
I am completing an email-test (which they say I "can use any available help and resource").
One question is to do with the differences between private and protected class members, along with an example of their use. For protected methods I have written the following:
"Protected class members open the implementation of the class (in regards to the protected variables) to friends, inherited classes and inherited classes friends. I would use a protected variable or a private variable with a protected getter/setter to allow more direct access to the classes implementation without exposing the variables as public."
#134989 - tepples - Thu Jul 19, 2007 1:16 am
While learning Python for work, I came out PEP 8, which called C++ protected methods a "subclass API". So here's my best explanation of 'protected' in Java and C++ (again, IANAL):
A class's protected members make up the API that its subclasses use.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#134995 - sgeos - Thu Jul 19, 2007 4:12 am
| keldon wrote: |
| (which they say I "can use any available help and resource") |
What a silly thing to say... these instructions boggle me. In short:
Private: For this class only. (And friends.)
Protected: Like private, but accessible to derived classes.
http://www.linuxquestions.org/questions/showthread.php?t=215399
http://msdn2.microsoft.com/en-us/library/ms858728.aspx
Google is your friend.
Don't forget private inheritance (with regard to protected class members):
http://www.parashift.com/c++-faq-lite/private-inheritance.html
-Brendan
#135004 - keldon - Thu Jul 19, 2007 9:41 am
lol, I know the difference between the two. What I'm talking about is the real world reasoning for using a protected class member. I don't want to give an example of use implied by the definition like, "use protected class members when you want derived classes, friends, and derived classes friends to have access to a particular variable" ^_^
My complete answer actually defines it with, "Protected class members can be viewed by the class, its friends, derived classes and derived classes friends whilst private class members can only be viewed by the class and its friends"
What I am putting together is the real world reasoning for it, or maybe I am over thinking it.
How about, "A good example of using protected class members is with a big number API. The BigNumber class is immutable, however the Maths class is declared as a friend so that it can access its protected variables and perform efficient calculations on the BigNumber type"
#135022 - keldon - Thu Jul 19, 2007 1:13 pm
Well I sent it off with the above answer for an example of use. Let's see if I get on to the next stage of the process.
#135052 - sajiimori - Thu Jul 19, 2007 8:07 pm
Well, for one, "protected" should be considered "almost public", rather than "almost private". If your class is intended to provide certain invariants, those invariants are broken if protected members expose the ability to break them.
For instance, if a Character class is supposed to keep the character's shadow synchronized with its body, the class shouldn't provide either public or protected methods that allow the shadow to be moved independently (e.g. a method returning a non-const pointer to the shadow).
Basically, class members consist of private and non-private members. The distinction between protected and public is often more like a comment than an actual restriction: "protected" usually says "general clients probably don't care about this," rather than "general clients musn't have access to this."
Exceptions:
A protected destructor is very important for base classes that don't have virtuals, to prevent deleting an object via a pointer to the base.
Also, "protected" is more meaningful when the concrete type of the object in question is known at compile time. For instance, even if the Character class provides a protected method to move the shadow independently, individual classes in the hierarchy can claim shadow synchronization as an invariant for themselves but not their derived classes. To illustrate:
| Code: |
void example()
{
// At least *this* guy has a synchronized shadow.
Character byValue;
// It's still synchronized even after this, guaranteed.
doAnythingYouWant(&byValue);
// The same can't be said here. Who knows what the
// derived class did with it?
const Character& byReference = getCharacterReference();
}
|
#135072 - sgeos - Fri Jul 20, 2007 12:05 am
| keldon wrote: |
| What I am putting together is the real world reasoning for it, or maybe I am over thinking it. |
My honest thoughts on protected members are "sometimes that is what you want".
It looks like I agree with sajiimori- use protected members when you need to do something and public members would be silly. (This happens, although one could argue that the classes need to be rethought.)
-Brendan
#135093 - sajiimori - Fri Jul 20, 2007 4:31 am
Glancing through the entire codebase for my last game, there were very few legitimate uses of 'protected'.
I used to think virtuals needed to be non-private for derived classes to override them, but now that I know you can override private virtuals, I'd estimate that 95% of the protected members in our codebase can be made private without any significant tradeoffs.
#135118 - keldon - Fri Jul 20, 2007 8:52 am
Hmmm, well a virtual private method's behaviour is what is expected when it is protected with an exception: the friend of the derived class can no longer access the method.
Are there any documents on this that I could add to the MUL? If anything I could link to this thread!
#135207 - sajiimori - Fri Jul 20, 2007 10:43 pm
I don't know of any good material, but I'm sure it's out there. My opinions on it are just from experience.