Should you ever use protected member variables?

up vote40down votefavorite 5	Should you ever use protected member variables? What are the the advantages and what issues can this cause? oop protected share|improve this question edited Oct 9 '09 at 23:03 Jeff Atwood♦ 29.1k36114127 asked Aug 31 '08 at 18:22 John Channing 3,16932347
	add comment

10 Answers

activeoldestvotes

up vote41down voteaccepted

Should you ever use protected member variables? Depends on how picky you are about hiding state. If you don't want any leaking of internal state, then declaring all your member variables private is the way to go. If you don't really care that subclasses can access internal state, then protected is good enough. If a developer comes along and subclasses your class they may mess it up because they don't understand it fully. With private members, other than the public interface, they can't see the implementation specific details of how things are being done which gives you the flexibility of changing it later. share|improve this answer edited Nov 29 '10 at 13:19 answered Aug 31 '08 at 18:34 Allain Lalonde 25.6k35122181

1   Can you comment on performance of protected variables vs a private variable with an get/set method? –  JakeJun 24 '10 at 13:56 2   I'd say it's not something worth worrying about unless you find through profiling that the bottle neck ends up being the accessors (which it almost never is). There are tricks that can be done to make the JIT smarter about things if it ends up being an issue. In java for example you can hint that the accessor can be inlined by marking it as final. Though honestly, the performance of getters and setters is far less important than dealing with system organization and with the actual performance problems as determined by a profiler. – Allain Lalonde Jun 25 '10 at 18:07 7   @Jake: You should never make design decisions based on performance assumptions. You make design decisions based upon what you think is the best design and only if you real life profiling shows a bottleneck in your design, you go and fix it. Usually if the design is sound, the performance is good as well. –  MeckiNov 25 '10 at 17:35  add comment

up vote19down vote

The general feeling nowadays is that they cause undue coupling between derived classes and their bases. They have no particular advantage over protected methods/properties (once upon a time they might have a slight performance advantage), and they were also used more in an era when very deep inheritance was in fashion, which it isn't at the moment. share|improve this answer answered Aug 31 '08 at 18:42 Will Dean 24.5k34073

add comment

up vote14down vote

Generally, if something is not deliberately conceived as public, I make it private. If a situation arises where I need access to that private variable or method from a derived class, I change it from private to protected. This hardly ever happens - I'm really not a fan at all of inheritance, as it isn't a particularly good way to model most situations. At any rate, carry on, no worries. I'd say this is fine (and probably the best way to go about it) for the majority of developers. The simple fact of the matter is, if some other developer comes along a year later and decides they need access to your private member variable, they are simply going to edit the code, change it to protected, and carry on with their business. The only real exceptions to this are if you're in the business of shipping binary dll's in black-box form to third parties. This consists basically of Microsoft, those 'Custom DataGrid Control' vendors, and maybe a few other large apps that ship with extensibility libraries. Unless you're in that category, it's not worth expending the time/effort to worry about this kind of thing. share|improve this answer answered Sep 1 '08 at 3:09 Orion Edwards 50k23134211

add comment