Object-Oriented Is Not Dead
Object-oriented programming (OOP) has gone through the mill of being adored, to suddenly hated by the masses. While it’s hard to discern how much of that love, hate, and intensity is fake news, the verdict is that the idea of object-oriented is not dead.
The issue isn’t object-oriented itself. The issue is how object-oriented was, is, has been, implemented. Legacy methodologies of OOP such as inheritance patterns are being regarded as insufficient to deal with the modern demands of a much larger codebase with more moving parts.
This isn’t OOP’s fault directly. Some patterns are simply behind in the times or are unsuitable at certain scales. Sometimes, the developer behind the code just hasn’t caught up with the memo yet, or they only know one OOP pattern.
Everything Is an Object
In the beginning, some guys at MIT in the late ‘50s came up with the idea that everything is an object. Sure, the idea of “objects” itself isn’t exactly new, but in programming, this was akin to a philosophical breakthrough.
The way we function as a civilization depends on our ability to communicate our personal translations and experiences of the world. Language is the way we facilitate this — whether it be verbal, non-verbal, visual, performance arts, music, or writing that captures the complexities of an idea in a simple way. Sometimes we mix and match to further enrich our experience of the idea.
For programmers, code is a communication bridge between us and digital machines. To classify everything as an object is a way to simplify the translation of business rules and interactions with their various action points.
Objects are essentially an organization tool that may also contain descriptions and abilities to perform actions — also known as, properties and methods. How these properties and methods are internally arranged to construct the blueprint for the object, often known as a class, is dependent on the scenarios and the developer’s knowledge of different implementation of object-oriented patterns available.
Most popular programming languages such as C++, Java, Python, and PHP all support the idea of objects. However, they also support other models of thinking and are not exclusively object-oriented, meaning that they are also capable of imperative and procedural methodologies.
Your variables are objects. Your functions are objects. Your arrays, your numbers, even your Objects are objects. This is important because it means you can assign properties to them. It’s also why we have an assortment of predefined properties available to us such as
length for arrays and
arguments for functions.
Stop Right There. What About Functional Programming?
Functional programming is a pattern that is currently being spoken about like it’s the thing that will put object-oriented into its grave. However, it’s a completely different method of translating ideas and runs on the premise of inputs, outputs, and functional machines.
reduce() are functional array methods that help reduce the complexity of code and potential points of failure.
Over the years, programming languages have come to a silent consensus that a single way of thinking can’t possibly cover all the potential bases. It’s also why many programming languages have evolved to be multi-paradigm to prevent themselves from alienating developers with undetermined cases in the wild.
Another new feature that’s currently in the final stage of review is
private variables in classes. There is limited scope let but not an actual direct way of implementing the idea of
Everything is made of ideas and one of those ideas is that everything is an object. Whether this is true or not is a completely different and potentially existential debate.
Object-oriented isn’t dead. Nor is it close to being dead. Rather, its hype has just deflated a little as the flaws in its implementation, such as classical inheritance patterns, come into view. However, patterns that don’t scale well don’t mean the end of ideas. Adaptations are growing as more people explore OOP to help solve their particular problems.
Legacy code is always annoying to deal with and a lot of the time, it’s written with the idea of object-oriented in mind. However, one shouldn’t dismiss object-oriented completely, but learn from how things fell apart.
At the end of the day, it doesn’t matter what paradigm or pattern you use. Your code will always age and chances are that someone in the near or far future will judge your chosen solution and deem it impractical because the code has grown out of its implemented patterns.