Role of OOD
You can write code that works. You don’t need OOD to make your program run. You don’t have to use any newfangled inheritance-supporting language. You can make programs that work in old BASIC, or Fortran, or COBOL or even assembly language. OOP/OOD/OOA, none of that is necessary if you want to just make a program that runs. Bash scripts, or even Batch files may be sufficient.
OOD doesn’t make your code run faster. Or even necessarily sooner (though good libraries are not to be underrated). It doesn’t make your teeth brighter or your breath fresher. It won’t grow hair on a cue ball.
But making it work at all isn’t the question. What OOD does is allow your program to have an advantageous structure. It doesn’t extend your ability to write code that works, but it extends your ability to extend code that works. It guards your software against becoming increasingly hard to change over time. It’s about the shape of your code.
OOD absolutely does provide tools (patterns, language, etc) that allow you to manage the dependencies that would otherwise make the maintenance of your software an ugly proposition. I don’t know anything else that OO does, except make work more fun. Things stay “new” longer.
I will tell you that the convenience of an OOPL is addictive, and that once you really grok OOD you will not want to try anything inferior in expressive capability. This is doubly true for dynamic OOPLs. But any time an OO person claims that OO will do anything else, it is probably because they’re trying to sell you something.
Me, I’d like to sell you on using Python for your next project.


