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…)