Warning: Purely technical.
This is from a series of articles I had written for a journal.
The one good thing about being a fresh graduate was that I was given the cubicle by the corner. This was a particularly desolate corner of the office; Tom must have thought that it would be better to keep the novices as far away from his group as possible. I loved my private corner; it even had a small window through which I could see seagulls.
Meeting in 5 minutes at the fishbowl- the message flashed across my screen. The third meeting of the day, and it was not even lunchtime. I had a suspicion that Tom had some weird quarterly objectives.
"Everyone should start putting in double the effort" Tom was eyeing each of us in turn- his eyes glimmered for a second when they passed Valery. "From now on, we are going to have daily code reviews". The poor chap who had to bear the brunt of today's surprise was Kevin.
Kevin, I have a question about the DoStuff function of the BuildBase_t class. It is defined as a private pure virtual function.
Virtual void DoStuff(void ) = 0;
How could one create a concrete derived class since this function cannot be overridden in a derived class?
Tom, as well as the others in the room woke up. Kevin looked at me bewildered then muttered something like access control is independent of polymorphism and carried on. It took some time for realization to dawn on me.
Access control is independent of virtualness. As I sat there thinking about this, I could hear the voice of my guru "Virtual functions should be treated very much like data members " make them private, until design needs indicate a less restricted approach is indicated. It is much easier to promote them to a more accessible level, than it is to demote them to a more private level"
Yucks, virtual functions should be created private by default! I couldn't imagine how silly my question would have sounded to Kevin.
"Kevin, your DoStuff function is incorrectly defined private" this time it was Valery. The DerivedBuild_t class I am working on won't be able to access this function and so can't override it. How am I supposed to create a non-abstract derived class?" Tom looked up from his spectacles and decreed: "Kevin, make that function public". Tom had a twinkle in his eyes as his glance came to rest on Valery.
Kevin wasn't willing to give up that easily. "Access control specifies only that Derived_t cannot access Base_t::DoStuff(). The function is still 'visible' from Derived_t; it is just not 'accessible' and we CAN override Base_t::DoStuff(). So the above construct is perfectly valid. The only thing to note is that within Derived_t::DoStuff() we cannot invoke Base_t::DoStuff() since this is not accessible. Tom, not too pleased with the condescending tone of Kevin, quickly deflected any culpability to me. "The point of wasting my time on this review is to make sure that the freshers in this group learn good programming practice; tell me what you understand from this" his glare settled on me.
"Use private virtual if you don't want the derived class to access the base class version of the method; protected virtual if you want to do above. and yeah, avoid using public virtual."