Thread: Why use private?

I've been thinking about this recently. This question isn't specific to C++, but a general OO question. Why would you ever want to use private instead of protected? If you are the leaf node class, you don't lose any encapsulation and if you're a parent class, your children are going to want access to your members, otherwise a lot of the benefits of inheritance are lost. I can't think of any scenarios where a parent would want to restrict its childrens' access to its members.

If you are the leaf node class, you don't lose any encapsulation and if you're a parent class, your children are going to want access to your members, otherwise a lot of the benefits of inheritance are lost.

O_o

You have a couple of misunderstandings.

First of all, "Final" classes are ......... Saying "It will never, ever be useful to further refine this class and its implementation." is retarded. With that in mind, you can't ever know that a class is truly a leaf of simply another branch. Thankfully, you can't even do "Leaf" classes in C++ without jumping through some serious "hoopage".

Second, you can lose encapsulation by making a member protected instead of private. Consider an example: if every protected interface in `Base' is implemented to assume that member `mPointer' is never null and that member is not private a derived class may change that member to null breaking the implementation. By forcing derived objects to mutate `mPointer' through a protected interface `Base' can guarantee that `mPointer' is never null.

Third, literally none of the benefits of inheritance are lost by making members or methods private if the interface is otherwise complete. It is only a matter of mutation by interface of mutation by overriding members and methods. For example, a derived class that needs to use `mPointer' may do so while `Base' manages the constraints that it requires if it provides an interface to do exactly that. Alternatively, if a derived class would only have used inherited privates to change the behavior of non-virtual functions that implies a problem in the chain of responsibility. Finally, an object is violating design principles if it would have only used inherited privates to store information unrelated to the base class interface and inherited implementation.

Soma

C++11 now supports final classes.

And how unfortunate that it...

Soma

What if you wanted to change one of the parent's member?

Refactor. Changing the base class will most likely mean you need to changed the derived class anyway.

First of all, "Final" classes

Who said anything about final classes?

Saying "It will never, ever be useful to further refine this class and its implementation." is retarded.

I agree. That's why private seems pointless.

if every protected interface in `Base' is implemented to assume that member `mPointer' is never null and that member is not private a derived class may change that member to null breaking the implementation

You should really be checking if a pointer is null before you use it. If it's never going to be null, then a reference should be used.

Third, literally none of the benefits of inheritance are lost by making members or methods private if the interface is otherwise complete.

I'd say it break the IS A relationship. If a base class can do X, the derived class should be able to as well. If you make X private, the derived class won't be able to anymore.

Changing the base class will most likely mean you need to changed the derived class anyway.

That's correct and exactly what the quote you are responding to said.

Who said anything about final classes?

You did by assuming that a specific class is a leaf instead of just another branch.

I agree. That's why private seems pointless.

Private facilities aren't subject to refinement as are protected and public facilities in normal branch classes; final classes, in whatever from, aren't subject to further refinement of at all. These are very different considerations. A private facility says "I (as in this class) expect this facility to be implemented in exactly this fashion for my interface but you can refine the interface and implementation independently.". A final class says "It will never be useful to refine this class.".

You should really be checking if a pointer is null before you use it.

Why? If higher level facilities guarantee a contract why should you verify it?

I'm being totally serious here, why verify the validity of a contract when that responsibility lies elsewhere?

Duplicating responsibilities is a good way to cause subtle bugs and trample performance.

Sure, checking a single pointer for null is cheap, but apply that same logic to large modern file systems. Imagine how slow your system would be if the file system driver had to check ever node in the system for validity before requesting a new node for file expansion. It would cripple your system. Instead, the driver has functions that do the job of guaranteeing (as much as is possible with unreliable hardware) the validity of "free store" every "free store" operation so the expansion code can safely assume the "free store" is ready to go.

If it's never going to be null, then a reference should be used.

That's a good rule of them for function parameters but not so much for class data members.

That aside, I can make a reference null. It is a violation of the C++ contract, but I can absolutely do it.

Are you going to start checking that a reference isn't null just because I can be a dick?

No. Of course you aren't. That would be foolish. You expect higher level facilities (in this case the C++ compiler) to do its job and the programmer to honor that contract.

The situation I'm explaining is exactly the same; you expect the `Base' class implementation to hold to that contract so checking it is meaningless.

If a base class can do X, the derived class should be able to as well.

True. However, private facilities aren't subject to this logic because the goal of "OOP" is programming to an interface not an implementation. Privates facilities are not part of the interface. They are part of the implementation. Consider the interface `doSomethingAwesome': if the `Base' implementation of `doSomethingAwesome' is implemented in terms of the private method `doSomething' derived classes can still `doSomethingAwesome' by doing the same thing the base class does (inherited implementation) or do something entirely different (override implementation). The private method used to implement `doSomethingAwesome' doesn't break anything.

If you make X private, the derived class won't be able to anymore.

That situation can't, by the very definition, violate the "IS-A" relationship. The "IS-A" relationship is about object substitution by interface leaving assumptions, contracts, preconditions, postconditions, and so on intact. The private aspects of an object aren't part of the interface. They are only part of the implementation.

Soma

Originally Posted by phantomotap

And how unfortunate that it...

in a way, I agree, but I can see that it might be useful under some circumstances.

in any case, simply making your destructor non-virtual is usually enough to make all but the most trivial derived classes act strangely.

I personally don't understand why parts of the standard C++ library are effectively final, like std::string. it's not impossible to derive from it, but it's usually not advised, because it doesn't have a virtual destructor, or any virtual functions. lots of other stuff in the standard library can be subclassed, and I have always felt like std::string is missing some things that would be very useful, but if I want custom behavior, I have to make a whole new class, when it would be much easier to simply derive from it and add the things I want.

O_o

I know what you are saying, but that's not exactly the right way to look at it.

You can derive from the standard classes; you just can't use them with inheritance based "OOP" in mind. You can derive and use them with other forms of "OOP".

I have read the logs from the governing group and you probably wouldn't be satisfied with the rationale even if you read it. [Edit]The rationale simply isn't very good.[/Edit]

Be one with the standard and accept. ^_^

Soma

Who said anything about final classes?
You did by assuming that a specific class is a leaf instead of just another branch.

I'm not sure why you would say a leaf class is final. Would you say that a leaf node could never become a branch? I said leaf because it has the least weight associated with it AFIAK. A leaf class simply means there is currently no class extending it. Nothing more.

In your doSomethingAwesome example, wouldn't you prefer to have the flexibility to redefine the helper function?

A leaf class simply means there is currently no class extending it.

That's true, but in framing your original question one of your assumptions was that a class didn't gain anything from private over protected semantics because it was a leaf class meaning that no class derived from it. You are, in making that one, also assuming that no class ever will derive from it making it final. The second a class does derive from that class the core of your assumptions (that nothing of semantic value from private is gained) vanishes.

In other words, I brought up final because you query is framed assuming final.

In your doSomethingAwesome example, wouldn't you prefer to have the flexibility to redefine the helper function?

Why? Seriously, take a minute to answer that question. Provide an example, real code, to illustrate your point.

Soma

You are, in making that one, also assuming that no class ever will derive from it making it final.

You're putting words in my mouth. I never said, nor insinuated, such a thing. Saying no class is currently derived from some class A does not make the assumption that no class ever will.

Why? Seriously, take a minute to answer that question. Provide an example, real code, to illustrate your point.

My view is probably too biased. Any example I come up with would probably result in you suggesting that the helper function shouldn't have ever been a helper function in the 1st place.