It's also a shitty way to do program organization! The basic idea of classes is very simple: the ability to instantiate new "global" spaces. It is not supposed to be used to organize your codebase because you'll never, ever get your scope right before you actually write it, and using a class hierarchy to organize things like this is just too hard to change later. So you get kludge.

The first thing to do is assume you'll fuck it up. Now you implement a strategy to handle those failures, and that means compartmentalization. Start with the biggest, most vague things your program needs to do. Input, Processing, Output. Now think up interfaces for those things, not classes. Your interface can be a class (or more likely a bunch of them), that's fine if it fits your needs. It can also be a free function library, that's fine too. Build it any way you want, because it's a conceptual thing, it doesn't have to be concrete and it definitely does not need the keyword "interface".

Just keep em out of eachother's business, and never, ever let one layer talk to a different layer. Input should never be talking directly to anything inside of Processing, you should use Processing's interface. Now you have walls, so if you fuck up inside any one of those you won't have to rewrite all three. And even more importantly, you can even fuck up on the interfaces! The interface can be rewritten fairly easily, because it's only one layer and there's no crazy web of interdependencies between the two sides of the interface.

Now recurse. I can't help you here, because the only thing I know all programs need is input, processing, and output. However just making sure these things are separated will do a lot for you, and I've seen a lot of code that does not formalize that simple separation (because despite its simplicity, it can still be a lot of work).

I generally write things as shallow as possible until I need to push them further back, so often my first pass at the input, processing, output will just be simple classes talking to each other with main tying it all together. As my needs get more complex I change things, pushing the actual input handling deeper while keeping its old top level interface. When the interface needs to get more complex I only have to change it on the one layer.

You'll mess up in there somewhere. Make the wrong choice, have to rip something out, maybe even have to rip something big out. But you'll never be tempted to just throw it all away and rewrite.

PS Public APIs are an entirely different monster... err story, and I'm not good enough to say anything about them (is anyone?).