During my initial coding endeavours, I found Object-Oriented Programming (OOP) to be one of the most complex concepts. Fundamentally, OOP is a coding methodology that places emphasis on data. Since the 1970s, OOP has been an industry standard, and modern-day programming languages are, predominantly, built on OOP foundations.
In his lightning lecture on C++ 2023, Jon Kalb brought up an intriguing point. It seems that in recent times, many programmers have either steered clear of discussing Object-Oriented Programming (OOP) or have exhibited a preference for functional or procedural programming. Does this indicate a significant shift in the traditional way of doing things? Are OOP programs now extinct? Thankfully, the answer to both these questions is a firm ‘no’.
There is an increasing acknowledgement of the existence of numerous ways to develop software. Even though this may not be pertinent to the average individual (as long as the intended outcome is accomplished with a single click), it can pose both difficulties and opportunities for software developers.
A programming paradigm is characterized as:
Could you furnish me with a series of instructions for attaining the numerical value of ten? This would resolve the quandary of how to achieve the number ten.
It is likely that there exist multiple ways to attain the desired outcome, though the two most immediate ones that spring to mind are either multiplying 2 by 5 or adding 5 twice. This is a mathematical matter, and the likelihood that most of us would opt for the same methods highlights a shared pattern of thinking.
When conversing about programming languages, the term “paradigm” is commonly employed to allude to a group of languages that operate on comparable assumptions. Notable examples of object-oriented languages comprise of Python, JavaScript, and C#, while C follows a procedural approach and LISP is characterized as functional. In other domains, the term might describe a consensus on a shared set of notions, attitudes, and aesthetic choices.
If the principles behind Object-Oriented Programming (OOP) and Functional Programming (FP) seem unknown to you currently, there is no cause for concern; we can furnish an explanation. Despite the differences in syntax and logic among programming languages, they all adopt a similar approach for identifying and solving problems.
Discover the main contrasts between Object-Oriented and Functional Programming
The concept of an ‘object’ – an entity endowed with both properties and behaviours (methods) – forms the foundation of object-oriented programming (OOP). Alterations to attributes can be effected by the methods; however, objects ought to be autonomous, so that no external changes are made in an unforeseen manner.
For the purposes of this illustration, let us imagine a cake. Attributes include size, shape, flavour, and appearance while methods of decoration comprise of various approaches (such as eating it, gifting it, or adorning it with candles). There is, of course, a greater degree of complexity involved, and this includes classes and inheritance, but to better understanding, let us maintain the example of our cake as it is.
When employing Object-Oriented Programming (OOP), it is critical to keep in mind that data can be modified at any point. Every piece of information is deemed an independent entity, akin to a cake that can change when it is processed. Consider a bakery, where each cake is considered a distinct object, and when a cake is sold, the slice approach can modify the data regarding this particular cake without impacting any other cake, table, or cup of coffee.
Functional programming places greater emphasis on the functions than on the data, as opposed to object-oriented programming wherein the focus is on the data itself. Stated differently, the emphasis is centered on the possible applications of the information.
What matters most is to consider the procedure for dividing the cake, rather than the cake itself. The sort of cake is inconsequential, provided that the given input is fitting. The approach will ultimately yield the intended output.
In functional programming, data is immutable, which means that it cannot be altered. Whenever a number is employed in an equation, the same answer is consistently produced, much like in arithmetic. This applies to any number, regardless of the class or type of object it is linked with, such as two fruits or vehicles. It is important to note that the number itself remains unchanged, irrespective of the outcome of the equation.
The question at hand is, “What is the reason behind the resurgence of functional programming?”
In the 1960s, when computers began to be more commonly used, the problems they could solve were comparatively less complicated. As the computing power surged, the complexity of the issues increased, and the volume of code required to solve them expanded accordingly. While inspecting a thousand lines of code for an error was not difficult, searching for a missing comma in a million lines was a far more daunting task.
Object-Oriented Programming (OOP) permitted us to tackle this problem. With our code structured into components based on data types and operations performed on them, it became easier to locate the section responsible for cakes if, for instance, a user’s slice was incorrect.
Thus, Object-Oriented Programming (OOP) provided a fitting remedy for the challenges experienced at that particular time. With the passage of time, it developed into the acknowledged norm for software engineers in structuring their work. Nevertheless, like every other set of regulations, its inadequacies may become conspicuous when applied extensively.
Object-Oriented Programming (OOP) necessitates abstract thinking. If we were to add two twos using OOP principles, we would require generating a class named ‘Number,’ with an occurrence of ‘2,’ as well as a function to add it twice.
According to Ilya Suzdalnitski, object-oriented programming (OOP) contradicts our inherent human inclinations. He contends that we typically view the world in terms of actions, such as eating to become hungry or going for a walk to stay healthy. As a result, we have a greater appreciation of the approach taken in functional programming when dealing with the representation of problems.
Detractors assert that, as programs have grown more complex, maintaining a legible and sustainable codebase has become increasingly problematic – especially for projects with a prolonged lifespan. The probability of complications arising rises significantly when more classes are incorporated, and their methods are subsequently altered later on down the line.
Unlike the dynamic behaviour of Object-Oriented Programming, functional programming strives to achieve stability. If an action is needed, a function is created to execute it, and remains unaltered until the next time it is required. Provided that the correct information is provided, the results are consistent and dependable.
It is commonly acknowledged that the Functional Programming paradigm puts extra demands on software developers. However, there are circumstances in which such constraints can be advantageous. As Suzdalnitsk aptly noted, they can help curb the havoc caused by an inadequate programmer.
By uncoupling data from its corresponding functions, we could potentially improve the stability of the system and reduce the management burden over time. Put simply: data should remain data and functions should remain functions, interacting only when necessary.
A growing number of software developers are discovering that functional programming is more instinctive than object-oriented programming and that different paradigms may be more effective in resolving certain issues.
Will there be a victor?
Absolutely not! The greater the alternatives at your disposal, other than a bothersome project manager who insists their approach is the only correct one, the better. In my experience, most software developers generally employ a blend of object-oriented programming and functional techniques (which is not ideal but not unusual).
As functional programming (and procedural as well) becomes increasingly widespread, identifying personnel who conform to a particular methodology or forming multi-paradigmatic teams capable of efficiently addressing specific circumstances has become a significant challenge for software development organizations.
Although I do not concur with those who prophesy the demise of Object-Oriented Programming (OOP), it is crucial to heed its critiques. As professionals, it is advantageous to be ready for a future in which our coding standards and techniques might be scrutinized.
