I've finally gotten to a point where I'm no longer dealing with understanding syntax issues, but now I'm writing so much code that I'm starting to have conceptual questions about the best strategies for organizing code into classes.
Say for example that I write a base class called Shape, and then I want to write derived classes for a Circle, DonutHole, and Donut. If my base class has coordinates x, y, and z, and my Circle class adds a radius, that makes sense to me. But then, the DonutHole... It is a circle, so maybe it can just be another instance of a Circle. However, let's suppose I want to make it have more unique variables such as innerRadius. Then, if I derive Donut both from Circle and DonutHole, I have the advantage of my inner and outer circles being named differently and isolated for focusing on unique features such a the different math that might be done on convex verse concave surfaces. There is a disadvantage, though, that the Donut gets two sets of x, y, and z variables. This type of situation has me confused about how to separate out each separate component in the most elegant way, strategically. I don't know how to best derive a new class from two classes that were both derived from the same class. Does that make sense? Any suggestions?
A Donut should derive from Shape and be composed of two Circles, which it allows the client to change the radiuses of but the coordinates are always set to match that of its own coordinates. There is no need for a DonutHole class.
I've also found something recently about virtual members where the shared base class can be declared as virtual when being incorporated as a base clasee. Suppose you have two derived classes B and C that have a common base class A, and you also have another class D that inherits from B and C. You can declare the base class A as virtual to ensure that B and C share the same subobject of A.