JS: Introduction to Object Oriented Programming (OOP)
2026-02-21 03:01 Diff
https://hexlet.io/courses/js-introduction-to-oop/lessons/definition/theory_unit

What is OOP? The answer you'll see if you look online will walk around inheritance, polymorphism, and encapsulation. If you dig deeper, you'll discover “message passing”, “class”, “abstract class”, “prototypes”, “interfaces”, “dispatching”, “mixins”, “protocol”, “multimethods” (and hundreds more scary-sounding words!). And each language has its own set of such entities found only in that language or in languages similar to it. And everyone will argue that OOP is not OOP without these concepts.

A further search will show a lot of “I don't understand OOP” articles on the web (such articles always accuse the author of not having mastered it) or “how do I understand OOP?” questions. There are typically hundreds of comments on these articles, where hot debates regarding the nature of OOP certainly take place. Among these arguments, there are bound to be people who say that JS is not an OOP language, there is no OOP without classes, and someone will say that the only OOP languages are Smalltalk and Lisp.

The cherry on top is a continuous flow of "OOP for Dummies" articles that try to explain OOP using animal examples (or ships or cars – anything from the real world), giving programmers a false sense of understanding of OOP. And then these programmers open the code, and there are adapters to databases and no real world:

Who is to blame and what can we do?

OOP has a long and complicated history. The term OOP was coined by Alan Kay in the late 70s (and implemented in Smalltalk) and this is what he said about it:

For me, OOP is messages and local hold; protecting and hiding state; and then after, linking everything. This can be done in Smalltalk and in LISP.

I thought of objects as something like biological cells, and/or individual computers on a network that can only communicate through messages.

It's funny, but in a way, he anticipated the Internet

Then came the C++ language, which inspired the book “Object-Oriented Analysis and Design with Applications”, in which Grady Booch (famous, among other things, for creating UML), described the very “polymorphism, inheritance, and encapsulation” that we mentioned earlier. C++ became mainstream, and all subsequent OOP languages began to copy it. When Alan was asked about OOP in C++, he said the following:

When I came up with OOP, I didn't mean C++

A lot of time has passed since then. The modern (this doesn't mean the best, just the current state of affairs) understanding of OOP is incredibly different from what Alan Kay had in mind. This is not to say that his ideas are gone. However, occasionally they take on new forms and operate on a different level, though some developers continue to insist that the real OOP is Alan Kay's OOP and that everything else is wrong. We're not going to dwell on this in detail. The most important point to keep in mind is that it's crucial to understand which OOP programmers are referring to when they start talking about it to avoid disagreements and even fights. OOP is one of the “religious” topics.

Modern OOP isn't a strictly grounded theory, unlike functional or automata programming. It's a large variety of approaches to organizing code and entities (classes, objects, etc.), which sometimes differ so much from language to language that it can lead to unexpected situations. PHP programmers are horrified by what Ruby calls OOP. The creators of Ruby, meanwhile, say that Ruby is a “true” OOP language, because in Ruby, “everything is an object”. And Java developers will never believe that JavaScript has OOP at all.

Finding the components that the program needs to be able to claim to be object-oriented in this case is crucial, as is getting rid of all the extraneous elements. As mathematicians say, find the basis (the minimum set of elements from which everything else can be derived).

OOP is attributed to many things that exist or existed just fine today in many languages without OOP. So when you hear about some advantages of OOP, don't take these words at face value. These advantages are usually advantages only because it is harder or impossible to do certain things in another way in this particular language. You can always find a language in which these same concepts are solved very elegantly and efficiently but without classes and objects.

Why, then, is it necessary to learn OOP? It's this approach that has come to dominate popular languages. JS, fortunately, has a strong enough multiparadigm (i.e., you can write in different styles). In other words, JS programs can easily combine different approaches such as functional programming and OOP. Where justified, we will implement the code using different styles. Then it will be easier for you to separate the essence of the problem from the way it's solved. You'll discover how to choose the best problem-solving approach without always relying on the syntax you've studied.

Learning

There's one important thing to keep in mind when studying OOP. No single course can provide you with the idea of OOP you have in your head from beginning to end. It takes years of experience, digging around in bad and good architectures, rewriting code, and most importantly, constantly analyzing what has been done, for improvement to occur.

The good news is that newbies aren't required to do this. It's enough to know the general concepts, some features of JS, and the syntax of all the necessary constructions. The rest will come with an experience. What Hexlet gives you in courses is much more than required for employment.

JS should be mentioned in particular. There are several behavioral characteristics of many OOP-related features. Enough for several books and, unsurprisingly, such books have been written. They are free and available on GitHub. Where appropriate, you can find references to chapters from these books in the supplemental materials. The courses themselves focus on big ideas, without digging into the minutiae. Otherwise, it'll be easy to lose track of the narrative.