Object-Oriented Programming – Is ‘Protected’ Reasonable Outside Virtual Methods?

encapsulationobject-oriented

so, suppose you have some fields and methods marked protected (non-virtual). presumably, you did this because you didn't mark them public because you don't want some nincompoop to accidentally call them in the wrong order or pass in invalid parameters, or you don't want people to rely on behaviour that you're going to change later.

so, why is it okay for that nincompoop to use those fields and methods from a subclass? as far as i can tell, they can still screw up in the same ways, and the same compatibility issues still exist if you change the implementation.

the cases for protected i can think of are:
non-virtual destructors, so you can't break things by deleting the base class.
virtual methods, so you can override 'private' methods called by the base class.
constructors in c++. in java/c# marking the class as abstract will do basically the same.

any other use cases?

Best Answer

Yes.

A situation where a non-virtual protected method makes sense might be something like bool IsInitialized(). The class is designed to be sub-classed. The sub-class might provide new methods, or overriding methods. In either case, before these methods can be run, it is important to check that the class is initialized. So the IsInitialized() method is provided for that purpose. It is intended to be used by the new or overriding methods in the sub-class only, and not the calling code. It is also intended that IsInitialized() not be overridden. The way to provide this is by declaring IsInitialized() to be protected and non-virtual.

Related Solutions

C++ Protected Methods – Real-World Scenarios

Here is an example

class Base {
public:
  // other members ...

protected:
  ~Base() { }
};

Used as a non-polymorphic base class. But users will not be allowed to call delete baseptr; on it because the destructor is inaccessible. Since it has no virtual destructor, allowing people to do that would be undefined behavior. See "Virtuality" by Herb.

C# – Empty virtual method on base class VS abstract methods

In this case the base class should know nothing of SectionA. The derived class should implement the extra properties that that type needs.

For certain operations where another class needs to pull information out regardless of the type of document you will want that method on the base class ideally virtual with a basic implementation and allow derived classes to override it if needed (eg ToPlainText which would just output all the sections of a document would be on Document, FancyDocument can override the implementation to also output SectionA).

For instances where another class doesn't care about the type of document but does care if it has certain properties use interfaces. IDocument would have all the common sections and Document would implement it. IDocumentWithSectionA would inheerit IDocument and FancyDocument would implement that. This then lets you derive another NeitherFancyNorNotFancyDocument that has SectionA which can also implement IDocumentsWithSectionA.

Obviously You'd have more useful names than IDocumentWithSectionA but that depends on the usecase.

TL;DR use the abstract class for what should be common to all documents and some common functionality, use interfaces as the contract saying what a document has.

Best Answer

Related Solutions

C++ Protected Methods – Real-World Scenarios

C# – Empty virtual method on base class VS abstract methods

Related Topic