abstract classes 2

Prata, C++ Primer Plus, p. 677:

"One school of thought holds that if you design an inheritance hierarchy of classes, the only concrete classes should be those that never serve as a base class. This approach tends to produce cleaner designs with fewer complications."

Do most of you advanced programmers here adhere to this rule?

I kind of picture the hierarchy of classes more or less like the taxonomical scheme used in biology, for which this principle does make sense: There is no object that is a mammal, for example, (abstract class) without belonging to a particular species such as deer, rabbit, squirrel, dog, etc. (concrete classes).

The only possible exception I can think of in terms of this analogy anyway is if you have an object about which you only have partial knowledge and aren't sure yet which concrete class it might belong to but still want to do work with it in the meantime.

Quote:

---

Do most of you advanced programmers here adhere to this rule?

---

No, that rule seems entirely too arbitrary. If it makes sense to derive from a class, then do it. Don't worry about it the base class is abstract or not.

The nice thing about this rule is that it entirely prevents slicing. I see no other value in it.

ok, thanks. Prata's examples in the book don't seem to adhere to the rule much either, so maybe this is just a view of some when dealing with complex class hierarchies--or maybe he's just exaggerating to make the point that this is possible and emphasize the importance of ABCs.

I guess as related question: Do you guys pretty much routinely declare your destructors as virtual, at least if there's any chance at all that the class may turn into a base class? Prata does make arguments that seem convincing to me for making destructors virtual for any base class.

I didn't know destructors could be defined as virtual. Not in standard C++ at least.

>> I didn't know destructors could be defined as virtual. Not in standard C++ at least.
Yes, they can and often should/must.

>> Prata does make arguments that seem convincing to me for making destructors virtual for any base class.
The more detailed answer is that if your class may ever be deleted polymorphically, then the destructor should be virtual. In other words, if anybody might call delete on a pointer to your class that actually points to a derived class, then your class better have a virtual destructor.

A simpler answer is if you expect your class to be used as a base class, give it a virtual destructor. Not giving it one is a good indicator to other coders that you didn't intend for it to be a base class. There are some occasions where you might want to derive from a class but not using polymorphically, which is why the simple answer isn't as complete as the more detailed one.

Personally, I try to think about whether I want the class to be a base class and make the destructor virtual based on that answer. If I'm not sure I don't have a problem making it virtual, though.

Quote:

---

Originally Posted by Aisthesis

Do most of you advanced programmers here adhere to this rule?

---

I try to design my class hierarchies such that the base class is abstract. However, I will not bite my nails if it makes sense for a base class to be concrete, or to inherit from a concrete class that derives from an abstract base class to inherit implementation instead of just the interface.

Quote:

---

Originally Posted by bithub

If it makes sense to derive from a class, then do it. Don't worry about it the base class is abstract or not.

---

I kind of agree, but to elaborate: if it makes sense to derive from a class, then use public inheritance if it is designed to be a base class. Otherwise, use private inheritance, but consider composition first.

Quote:

---

Originally Posted by CornedBee

The nice thing about this rule is that it entirely prevents slicing. I see no other value in it.

---

I think that there is other value, but it is somewhat related to the prevention of slicing. An abstract base class encourages the application of the dependency inversion principle, since using it means using an abstraction and programming to an interface. (Although a user could just use the concrete derived class without involving the abstract base class, and thus gain nothing from the principle, which would be the same if the user did not use a concrete base class as an abstraction.)

Aisthesis, I am not sure if I linked you to these articles before, but you could read:
The Open-Closed Principle
The Liskov Substitution Principle
The Dependency Inversion Principle
The Interface Segregation Principle

Quote:

---

Originally Posted by leeor_net

I didn't know destructors could be defined as virtual. Not in standard C++ at least.

---

Virtual Destructor Example

awesome! that should give me plenty to digest on this. I'm eager to check out your links, tx!

also nice to see that the rule isn't just complete air. laserlight's view seems healthy and flexible to me.

Quote:

---

Originally Posted by Daved

>> I didn't know destructors could be defined as virtual. Not in standard C++ at least.
Yes, they can and often should/must.

---

See, I figured I was forgetting something. I was actually thinking pure virtual destructors. Whoops... :)

Quote:

---

Originally Posted by leeor_net

See, I figured I was forgetting something. I was actually thinking pure virtual destructors. Whoops...

---

Destructors can also be declared pure virtual, except that you still need to define them since derived class destructors will invoke base class destructors.

Quote:

---

Originally Posted by Aisthesis

I kind of picture the hierarchy of classes more or less like the taxonomical scheme used in biology, for which this principle does make sense: There is no object that is a mammal, for example, (abstract class) without belonging to a particular species such as deer, rabbit, squirrel, dog, etc. (concrete classes).

---

Consider a real world example of a Window in a windowing system. A Window is a real thing -- a rectangular area of pixels on the screen which can be drawn upon and for which events can be received. A subclass of Window might be PushButton, which overrides certain Window behaviors to draw something that looks like a button and process mouse click events. The existence of PushButton does not obviate the usefulness of the base class Window, even though it naturally derives from Window.

The taxonomic analogy is just that, and should be interpreted as an intuitive explanation of inheritance, not a definition of it. Anyway, even in taxonomy, it is possible for subspecies to exist, so that we may have the species Canis lupus, the grey wolf, and also Canis lupus familiaris, the domestic dog. Both of these are real animals even though dog is a specialized subclass of wolf.

Quote:

---

Originally Posted by laserlight

Destructors can also be declared pure virtual, except that you still need to define them since derived class destructors will invoke base class destructors.

---

Well, true. I just tend to avoid doing that because it kind of negates the whole purpose of defining something as pure virtual. That's just my humble opinion, of course.

Quote:

---

I just tend to avoid doing that because it kind of negates the whole purpose of defining something as pure virtual.

---

The purpose of making something pure virtual is to make the class abstract. If you have no other function that you want to make pure, the destructor is the best choice.

good point, brewbuck on the subspecies. I think I've read too much Aristotle and hence had some vague prejudice that there was some "essence" category that's the lowest-level concept before you get to the individual.

And, in addition to subspecies, you might want separate classes at times for female and male of a given species.