Talk:C++ Programming/Classes/Abstract Classes/Pure Abstract Classes

=Abstract types and abstract data types=

The title of this page was named (I corrected it) "Pure abstract classes (interfaces or ADT's (abstract data types) )"

Pure abstract classes are the way to implement "abstract types" not "abstract data types". The two concepts are extremely different. Lets see what says the google bot with the define keyword:


 * Abstract type:

A type declared using the reserved word abstract. Only abstract types can have abstract operations. You cannot declare objects belonging to an abstract type; the purpose of an abstract type is to act as the parent for a class of derived types. www.it.bton.ac.uk/staff/je/adacraft/glossary.htm


 * Abstract data type:

A type whose implementation details are hidden and can only be handled using the publicly accessible operations provided for it. Not to be confused with abstract type. www.it.bton.ac.uk/staff/je/adacraft/glossary.htm

Moreover an interface is not the same to abstract type, they are implemented in the same way in c++, but the two concepts differ.

=Mandating base classes to be Pure=

Im not at all sure about this assertion:

"Note that there is a great temptation to add concrete member functions and data to pure abstract base classes. This must be resisted, in general it is a sign that the interface is not well factored. Data and concrete member functions tend to imply a particular implementation and as such can inherit from the interface but should not be that interface. Instead if there is some commonality between concrete classes, creation of abstract class which inherits its interface from the pure abstract class and defines the common data and member functions of the concrete classes works well."

There are two reasons why I disagree with this advice:
 * There are plenty if design patterns that require implemented functions within the base class, for example the Template Method pattern - f is non virtual, but uses virtual g and virtual h to do work, the user is responsible for deriving a class and implementing these virtual functions; and
 * There are plenty of libraries out there that buck this advice - for example, the QObject in Qt is actually quite heavy weight and provides a lot of facilities for both derived objects and clients of the object. There would be all kinds of use cases that wouldnt be possible if QObject was pure.

This advice makes perfect sense when you are describing something akin to a callback interface, or when implementing something following the Strategy or State patterns. Its just that a blanket statement that "Its bad, do do it. Ever" doesnt work.