Protected vs Private

There is no performance difference between private and protected. Access retrictions are applied at compile time, not runtime.

That being said, I would avoid protected data. Protected member functions are ok, but protected member variables tend to have long term code maintenance problems.

Quote:

Original post by SiCrane There is no performance difference between private and protected. Access retrictions are applied at compile time, not runtime. That being said, I would avoid protected data. Protected member functions are ok, but protected member variables tend to have long term code maintenance problems.

why?
they work preety much like private variables right?
so what would be the complication?

That's pretty much what I figured. But why would there be a maintainence issue with it? Maybe that's what my coworkers were getting at. I still think that unless there is a real reason why something should not be visible to it's derived relatives, it should be protected.

I always protect my variables in base classes.

ace

Well, if you make variables protected rather than private, it can introduce maintenance issues if derived classes use those variables, since derived classes are now dependent on those variables.

If you choose to change the functionality, such that those variables are no longer needed, say for example you want to split that functionality off into a seperate class, you will have to change every derived class that uses those variables.

A better way to do it, is to have protected methods that access the private variables. That way, derived classes are not reliant on the protected variables.

Quote:

Original post by Oxyacetylene ... That way, derived classes are not reliant on the protected variables.

So now they'll be dependent on protected member functions? I must be dense... but huh? How is that better?

It's better for the same reason that public functions are better than public variables. You can change the definition of the function without directly affecting entities dependent on that function.

Quote:

Original post by Oxyacetylene If you choose to change the functionality, such that those variables are no longer needed, say for example you want to split that functionality off into a seperate class, you will have to change every derived class that uses those variables.

That makes sense...but I think it is acceptable. I'd rather do that than use the functions suggestion. I'll just name any new variables differently if necessary.

Quote:

Original post by SiCrane It's better for the same reason that public functions are better than public variables. You can change the definition of the function without directly affecting entities dependent on that function.

That also makes sense. I haven't found this to be a problem though. Maybe if I worked on much larger scale projects it may become an issue but so far, I'm MUCH happier with protected variables.

I agree with SiCrane, not only can protected data members be bad mojo its abit of contradiction to what you where originally trying to do that is to provide loose coupling between unrelated types & modules, to enforce state invariants, to support liskov's substitution principle. By making data members protected you've just blown that all away by allowing clients (or yourself) to subvert that by derivation. Related sub-type should not be any different than the same privileges that unrelated types/modules have, inheritance should be about extending behaviors not implementation (theoretically speaking)

Quote:

Original post by helix That also makes sense. I haven't found this to be a problem though. Maybe if I worked on much larger scale projects it may become an issue but so far, I'm MUCH happier with protected variables.

Note my original post said "long term code maintenance problems." That may be a decision that you're fine with now, but if the project you are on is live five years from now, some code maintainer (and it could be you) will probably wish that you hadn't used those protected variables.

And if your project is big enough to need co-workers working on the same code base, than that time probably will come a lot sooner than five years from now.

I've a question regarding this then. I'm not formally trained, so a good deal of the CS theory quoted is Greek to me. I understand the general principle regarding the maintenance recommendation.

In my recent experience though, keeping certain variables protected has helped me greatly when I wish to slightly modify/extend the base class.

Er something like this is how it tends to work:

base{protected:foo;public:virtual do_stuff_with_foo();};child:public base{public:virtual do_[slightly different]_stuff_with_foo();};

Under what conditions is this sort of arrangement acceptable?
What sort of design arrangement is better for this sort of thing?

I could pass the 'slightly different' part as a function parameter, though I think in a few cases that is unweildy, since that places burden on the caller to know something it perhaps needs not to know.

Quote:

Original post by SiCrane Quote: Original post by helix That also makes sense. I haven't found this to be a problem though. Maybe if I worked on much larger scale projects it may become an issue but so far, I'm MUCH happier with protected variables. Note my original post said "long term code maintenance problems." That may be a decision that you're fine with now, but if the project you are on is live five years from now, some code maintainer (and it could be you) will probably wish that you hadn't used those protected variables. And if your project is big enough to need co-workers working on the same code base, than that time probably will come a lot sooner than five years from now.

This is worth special note - big projects = more people working on it = more potential problems with encapsulation and "future-proofing" = more boilerplate = even bigger project ( [cry] ).

Personally, I find that OO purism is a major enemy to OO productivity, and prefer to apply YAGNI somewhat aggressively.

Note that many languages supporting an "OO style" (most notably Python) do not provide equivalents to public/private/protected at all (OK, Python has __ prefixes, but it's just a name-mangling hack, the mangled name is not difficult to figure out, and noone uses it anyway). Any data/info on large-scale commercial Python projects out there and how they handle this stuff?

Quote:

Under what conditions is this sort of arrangement acceptable? What sort of design arrangement is better for this sort of thing?

In situations like the one outlined, I might make foo private, and put in protected Get/Set methods, like you would in a public interface. How you go about hiding it however really depends what foo is, and what level of access the derived classes need to it. I've never come across a situation where there wasn't a neat solution to this issue, although some required more laterial thinking than others.

Quote:

Original post by Zahlman Note that many languages supporting an "OO style" (most notably Python) do not provide equivalents to public/private/protected at all (OK, Python has __ prefixes, but it's just a name-mangling hack, the mangled name is not difficult to figure out, and noone uses it anyway). Any data/info on large-scale commercial Python projects out there and how they handle this stuff?

From a friend who's worked on a largish Python project, it seems like Python has less problems with inheritance screwing up encapsulation simply because Python code doesn't need inheritance nearly as often as C++ or Java, since Python is duck typed.

To me one of the strengths of C++ is the use of private data. Once done you can be sure that no other class or even subclass can change it, unless non-private setter methods are provided. This helps me sleep better at night when others use my code.

The use of protected depends a great deal upon whether you are producing code that others may interface with. In this situation, my view is that protected should not be used for interface classes, whereas it can be used for implementation classes.

When protected is used on the interface, you are introducing a bias for external users. They now must 'subclass' rather than 'use' the interface. This is generally not a good thing for the user of a class library.

For the implementation, it really depends upon the design issues at hand and what the implementors want to achieve. Protected has its uses to maintain data integrety between super-classes.

--random

I also subscribe to the concept that inheritance (driven by 'protected') should really be used primarily to reduce the amount of code written, and that 'composition' be used more. This makes for much more flexible , and, in my opinion, more maintainable code.

By the way, idea of composition is much closer to the basic concept of smalltalk and objective-c. There the real emphasis is on one class instance 'using' another class instance, and 'messages' between instances. In C++, similar ideas have emerged but are called 'composition' and 'wiring'.

--random