Original Article: https://blog.sigma-star.io/2024/01/people-dont-understand-oop/
Occasionally, I come across the opinion that object oriented programming (OOP) is an obsolete principle. This opinion sometimes goes hand-in-hand with observations that it is not longer touted as a “must-have” independent skill for a resume and job posting – compared to the 1990’s when it first hit mainstream programming as the hottest thing since sliced bread.
The general idea that OOP has declined is based on a misrepresentation of its role as a trend instead of a set of design paradigms that address issues in programming that have always existed. Sigma’s article contextualizes this further by representing OOD as an ideology underlying a set of skills rather than a static framework that can be applied to any situation. This distinction between OOD as a ubiquitous standard vs a set of integrated principles is where the disconnect lies.
The 1990’s saw the massive rise in popularity and mainstream adoption of languages like Java and C++ in industries that valued their large-scale and fast deployment potential. I think that much of that perceived value was bundled up with the idea that since object oriented design was foundational to these emergent technologies, then it must have an intrinsic value unto itself. However, as modern programming languages matured, that blanket assumption has been disproven, and in its place, has come an awareness that no tool or abstraction can remove the underlying requirement for careful analysis and planning in building applications.
My introduction to object oriented programming came when I was still coding in PHP 4 and I needed to model some complexity into an ecommerce web application that applied discounts based on parameters in a user account. PHP 4 supported basic object-oriented features like classes and objects but was missing core OO functions like visibility, interfaces, abstract classes and full inheritance. This posed potential security issues with payment and order processing that required a lot of additional code to implement.
In contrast, my latest significant experience with object oriented design was building an ARM assembler in Java that could parse instructions in binary or hex format for dozens of operation types, many with their own unique business rules. The incoming instructions fell into different logical categories of operation that the assembler had interpret using field codes that identified the specific operation being represented.
Since a 32-bit binary instruction represents billions of unique operations and values, including many illegal code combinations, determining which operation was being referenced, whether the instruction contained an illegal combination of bit values, and how to format the referenced operation, forced me to think initially in abstract terms. First, I had to classify all the different types of operations and organize them in a hierarchy that allowed me to create a taxonomy that I could then use as a basis for my assembler program design. With so many logical permutations, I could not afford any code repetition in my application. But I also wanted the flexibility to introduce additional operations if necessary.
This design problem forced me to think about instructions in a new way – as if I were the person that came up with original instruction set, as opposed to a programmer using them. After some design trial and error, I ended up creating 5 interfaces that could adequately define the behavior of billions of different operations. Ultimately, I only needed one Instruction class that used business rules and composition to parse an incoming instruction into the correct operation.