What is object-oriented programming (OOP)
Object-oriented programming (OOP) is an approach in which a program is viewed as a set of objects interacting with each other. Each has properties and behavior. OOP makes writing code faster and more readable.
Everyone usually starts learning programming by writing programs in a procedural style. The program expects some data as input, performs a series of procedures (they are also called functions), and then returns some results.
Conventional programming is often understood as procedural programming, which is based on procedures and functions. A function is a mini-program that receives some data as input, does something inside itself, and can return some data as a result of calculations.
Functions are useful when you need to pack many commands into one. For example, checking an e-mail address may consist of a single check for regular expressions or contain many commands: querying dictionaries, checking against spammer databases, and even matching against already known e-mail addresses. You can pack any combination of actions into a function and then call them all in one motion.
Procedural programming works ideally in simple programs where all problems can be solved, roughly speaking, with a dozen functions. Functions are neatly nested inside and interact with each other; passing data from one function to another is possible.
Initially, all programs were written with a procedural approach, but when the programs became extensive, it became clear that this approach was unsuitable; it was difficult to manage some entities and decompression. And when procedural programming was no longer enough, an object-oriented approach was invented.
OOP is used when writing operating systems, DBMS, compilers, drivers, and many application programs. For example, suffice it to say that almost all known browsers, Microsoft Office, Adobe Photoshop, and Illustrator, are products of object-oriented programming.
The main goal of OOP is to make complex code easier. To do this, the program is divided into independent blocks, which we call objects.
An object is a collection of data and functions, just like traditional functional programming. You can imagine that they just took a piece of the program, put it in a box, and closed the lid. This box with lids is an object.
Programmers agreed that the data inside an object would be called properties, and the functions would be called methods. But these are just words; they are the same variables and functions.
A fundamental building block in OOP is class. It represents a description (specification) of multiple objects from reality. A class is a template describing the properties, state types, and behaviors common to the entire set. Put another way: we describe in the class all the data that a real object should contain to solve a particular programming task.
We can think of a class as a programmer-created data type that contains its data types and functions.
Basic principles of OOP
Objects are characterized by four words: encapsulation, abstraction, inheritance, and polymorphism.
Encapsulation (also known as “information hiding”) is one of the main principles of object-oriented programming. With it, an object must provide its user with only the necessary management means.
For example, an office worker only uses the peripherals of a PC. He does not need to know the model of the processor, its architecture, the way of connection to the motherboard, etc. These components and the knowledge about them (processor, motherboard) appear hidden to him.
The creator of the classes determines what is hidden and what is publicly visible. This is done by explicitly defining as private any field or method that we do not want to be used by another class.
Abstraction is the process of hiding unnecessary details from the user. For example, when you send a message, you enter the text and press the send button. Your phone shows that the message has been sent, but what’s happening in the background when you tap send is hidden because you don’t need to know.
In other words, abstraction allows you to simplify complex concepts as much as possible and handle the simpler version. This is precisely why the stereotype is at the heart of OOP – you can think of very complex objects as simple ones and simplify the work process.
Inheritance is also a fundamental principle in object-oriented programming. Through it, a class can “inherit” methods and properties from another, more general class. Let me use an illustrative example with animals.
The wolf belongs to the family “Canidae” (which translates as “canine”). All wolves are quadrupeds, mammals, and predators. These characteristics of the wolf can be assigned to some more general class if we follow the association with animals – at the “class” or “order” level in the hierarchy of the animal world.
All classes corresponding to this characteristic are linked to this higher class. This means that they get this general information from that more high class, which saves you having to write it out every time for every class you want to have those attributes. This class, which is inherited, is called the parent class or base class (base class, super class).
Another important principle of object-oriented programming is the so-called polymorphism. Let’s go back to the animal example. We have defined a class – the family “Canidae.” But in this “family,” there are many and varied predators – from wolves to foxes to dogs. They have different behavior when it comes to hunting.
Polymorphism allows us to treat any of these animals as a member of the “Canidae” family and command it to make a catch, no matter what precisely the “animal” we’re steering is. To do this, polymorphism uses overwriting methods in inherited classes to change their actual behavior inherited by the base class. This is what allows for multiple different implementations of the same thing.
Benefits of object oriented programming
The first programs in high-level programming languages were not structured, and this did not cause problems because the amount of code was, by modern standards, negligible. In addition, there were no repositories then, there was no Internet, and replicating the source codes of software products was extremely difficult.
As hardware and software competed, the amount of source code in programs began to skyrocket. Now, to support it, a specific architecture was already required. Various approaches to the design of source codes began to be applied, and eventually, programming paradigms appeared. OOP stood out at once with several critically essential differences:
- Convenient division of development tasks between different programmers, departments, and companies. Modularity through encapsulation may have been a critical reason OOP is so widespread.
- Potential for scaling. You can add new components, extending the already written software – and everything will work.
- Processing of heterogeneous data structures. Thanks to polymorphism, OOP software can be flexibly modified, supplemented, and “updated.” This is an indispensable property for commercial products, and it is they who determine revenues and budgets and create a resource base for new and new projects.
The repetition of OOP code has led to the creation of class libraries. You can spend less and less time on getting the results already obtained earlier – and it’s not even essential who precisely and on what projects the previous developments were made. This is how the banana paradox began to take shape: on the one hand, simplification of development by replicating already implemented classes. On the other hand, there is a suboptimal use of hardware resources.
While developing a software product, extensions and additions already implemented in the connected libraries may be required, and then it remains only to use. Something similar is now used in many commercial products, not only software ones.
The idea of ”development in reserve” is quite convenient from a sales point of view. As well as choosing a high pace instead of perfectionism as a code. It is better to sell today and hand over the project tomorrow than to stretch everything out for years and fly out of the market.
For all its shortcomings, object-oriented programming makes it faster, more economical, and more convenient to manage the distributed development process to get working code. Yes, perhaps there are significant non-optimalities, even a lot of them. But the project is already working, at least in the form of a prototype. This is enough for presentations, getting the first customers, and implementations.
All the same, the initial marketing, interface, and many other ideas will have to be repeatedly refined and possibly changed. From the point of view of a company and especially a startup, it is more profitable to move faster.
The pros of object oriented programming can be summarized as follows:
- Easy to read. There is no need to look for functions in the code and determine what they are responsible for.
- Quickly to write. You can quickly create the entities that the program needs to work with.
- It is easier to implement extensive functionality. Since it takes less time to write code, you can create an application with many features much faster.
- Less repetitions. No need to write the same type of functions for different entities.
Minuses of object oriented programming
- Consumes more memory. Objects consume more RAM than primitive data types.
- Reduces performance. Many things are technically implemented differently, so they use more resources.
- Difficult to start. The OOP paradigm is more complex than functional programming, so it takes more time to start.
The future of OOP
Will object-oriented programming survive, or is it just a fad that will soon disappear?
Classes have found their place in most modern programming languages. This alone suggests that they are destined to stay. Classes will become a standard set of concepts for every programmer shortly; in the same way, many today use dynamic data structures and recursion, which were also a novelty twenty years ago. At the same time, classes are just another new construct, along with the others. We need to find out what situations they are suitable for, and this is where we will use them. Choosing the right tool for a particular task is a must for every artisan and even more so for every engineer.
OOP plunges many into a state of euphoria. The hype here and there promises us incredible things, and even some researchers seem inclined to consider OOP as a panacea that can solve all software development problems. Over time, this euphoria will gradually subside. And after a period of disappointment, people will probably stop talking about OOP, just like you can hardly hear from anyone today about structured programming. But classes will be taken for granted, and we can finally understand what they are: just components that help build modular and extensible software.
In the new century, multi-core and multi-processor systems began to spread massively. A little later, there was a need for distributed computing and computing on graphics processors. It turned out that OOP copes with such tasks much worse than functional programs. Even based on this one factor, one can doubt the endless dominance of OOP.
Of course, the proportions in development will change. It’s already happening. In addition, fundamentally different, new approaches will appear sooner or later – and they may become unattainably more productive, especially on modernized hardware.
Nevertheless, so far, OOP remains a reliable, convenient tool. Nothing seems to bode well for significant advances in the coming years, so you can safely use object-oriented programming as a personal career plan and to launch projects.