I want to tell a story about a software engineer named Bob. Bob is not his real name.1 Bob is not even a real individual. He’s a composite and a straw man.
Bob the software engineer says “there’s too many abstractions.” It’s a common criticism from Bob when he reviews code or code designs. He’s not applying a YAGNI or KISS principle. He’s not diagnosing an incorrect or poorly implemented abstraction. It’s something else.
Bob is a veteran software engineer. His formative professional experience was probably writing C code but he has long since transitioned to C++. He thinks he made the jump pretty well. He uses classes and considers his code to be objected-oriented. He appreciates the ability of a C++ class to colocate data and the functions that operate on the data.
If you ask Bob what he means by ‘too many abstractions’, he’ll explain that every abstraction has a cost. More abstractions mean more classes and more function calls and more overhead. He doesn’t like adaptors, decorators, or functors. He believes deep layers of abstraction are inherently too expensive.
This ‘abstraction is too expensive’ idea is curious for a software engineer engaged in true object-oriented design because object-oriented design fundamentally assumes that abstraction is cheap.
Unsurprisingly Bob doesn’t write object-oriented code. What he writes is tightly coupled procedural code wrapped in monolithic class definitions and he doesn’t understand the difference. This is not an OO versus procedural argument. Bob is creating bad code that abuses multiple paradigms. The point is he believes he is writing object-oriented code, yet he can’t grasp and truly leverage OOP because he can’t get pass the overhead issue.
OOP isn’t about optimizing for the machine; it’s about optimizing the construction and maintenance of the software. Quality and time-to-market are prioritized ahead of raw execution speed. Software that’s super fast but wrong and delivered late is worthless.
A good object-oriented design is an investment. The return on that investment is flexible, adaptable software that’s easy to repair, refactor, and extend.
OOP is not perfect and it’s not the only way to achieve adaptable software. But it is Bob’s professed paradigm and he’s failing to realize some of OOP’s most significant potential benefits. In essence Bob is attempting to practice OOP without embracing objects.
1How did I pick the name Bob? Some strange synaptic cross between Microsoft Bob and Bob the Builder.
Speaking of Microsoft and children’s programming: Do the rolling green hills in Windows XP’s default desktop background image remind anyone else of Teletubbies?