organization – With C#, in what way would it be problematic to have hundreds of classes derived from one abstract class?


With C#, I am defining the physical structure and behavior of a robot.

For the physical structure: I wrote an abstract “Unit” class. Other classes such as “Factory” or “Arm” are derived from Unit. So there is a hierarchy/tree of Unit objects that defined the physical makeup of the robot. For example, the constructor of Factory would create instances of Arm among other things as children. And those children reference the Factory instance as their parent. Unit objects only have methods to help define initial physical configuration.

The problem and my question: The hierarchy can be wide. It could also be deep down to something like “OuterBearingRace” for a Bearing under Rotor under Actuator under Arm under Factory. There could potentially be hundreds of classes derived from Unit. Someone on another forum mentioned that this could be problematic. So why would it be problematic and how would you do it differently?

Unfinished example code:

public class Factory : Unit{
public Factory(string unitName,Unit parentUnit,Transform parentTransform,Vector3 position,Quaternion rotation) : base(unitName,parentUnit,parentTransform,position,rotation){
    AddUnit(new Platform("Platform",this,null,new Vector3(0,0,0),Quaternion.identity)); //Platform derived from Unit
    float armSpacing = 457.2f - 152.4f;
    float armHeight = U("Platform").P("mainMountHeight").v;
    AddUnit(new Arm("Arm1",this,null,new Vector3(armSpacing,armHeight,0),Quaternion.identity,304.8f,50f)); //Arm derived from Unit
    AddUnit(new EndMill("EndMill1",this,null,new Vector3(armSpacing+600f,armHeight+304.8f/2f,0),Quaternion.identity));
    U("Arm1").AddAction(new IKLock("LockOnEndmill",U("Arm1"),null,U("EndMill1").transform));
}

}

For behavior, a Unit can have a tree of actions such as “DrillHole” or “GrabBarStock” that are derived from an abstract “Action” class. It’s the same scheme as the physical structure except methods are allowed to define dynamic behavior of the robot during run-time update calls.