I write embedded software and I often find myself structuring my code such that there is one large parent class that contains just about everything. For example, consider you want to model a hardware platform that can use swappable toolsets where each tool had multiple uses, I would make something like this:
class platform
{
toolA* a;
toolB* b;
}
platform* p;
class toolA
{
toolA_use1* one;
toolA_use2* two;
}
class toolB
{
toolB_use1* one;
toolB_use2* two;
}
class toolA_use1{...}
class toolA_use2{...}
class toolB_use1{...}
class toolB_use2{...}
Then when I want to do just about anything I will “drill down” to the relevant method or variable of the relevant object starting with the top-level class, like this:
p->a->one->someFunc();
Essentially EVERYTHING is contained in the ‘platform’ object p. Sometimes I have called it ‘d’ and the class name was ‘device’… and then I’d have things like d->IO->SPI->init(&SPI_Init_LCD)
, or whatever.
In reality I’ll use descriptive names of course, I just don’t think I can give a real-world example without giving away what I do (and likely who I work for, there aren’t many companies making these things). I’ve been doing this so long I haven’t really questioned if there is a good reason to do this differently… I’m questioning it now because recently I’ve inherited a large project that is not structured at all like this and I don’t like it. It’s “spaghetti”… everything is flat on the same level and interconnected to everything else rather than a hierarchy like I usually make (on top of the fact the previous author was using factories and abstract base classes for things that will only ever have one object instance…)
CHollman82 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.