I don't have much experience working with OOP, so I'm trying to understand what is the feature (or features) that would give you a great motive not to write some program in a procedural language, but rather write it in an OOP language instead.

I have thought of the following features of OOP and their impact:

  • Doing obj.func() instead of func(obj) doesn't seem that important.
  • Making variables private also doesn't seem that important (I find it hard to mistakenly access variables that you know you shouldn't access if for example you named them something like str_name_private).
  • Inheritance I think is just about not having duplicate code, so it also doesn't seem that important.
  • The only feature that I think is important is Polymorphism.

Is my assumption correct that Polymorphism can be thought of as the "killer feature" of OOP?

  • 1
    Polymorphism can also be done in non-OOP languages. Including polymorphism on more than just the first argument, multiple dispatch.
    – Andrew
    Commented Jul 20, 2018 at 22:10
  • 8
    OOP can also be avoided in OOP languages.
    – Erik Eidt
    Commented Jul 20, 2018 at 23:29
  • 3
    Do you have much experience working with large software projects? OOP is just one way of managing complexity, and the advantages of information hiding, encapsulation, and variable scoping may not become clear to you until you've worked on a large project with multiple developers. Commented Jul 20, 2018 at 23:36
  • 1
    What is a "killer feature"? Possibly it is the one that gives you a really big benefit that you didn't experience and/or have access to before. Or it is the one language feature that you use a lot. This will result in different developers having different ideas of what the killer feature is in any given language. Different languages would yield different ideas of what the killer features would be. Commented Jul 21, 2018 at 4:53
  • "not having duplicate code ... doesn't seem that important" -- reducing code duplication is possibly the single most important and fundamental principle for software engineering.
    – Denziloe
    Commented Jul 31, 2019 at 10:09

5 Answers 5


The killer feature of OOP is message passing. That is, the ability to talk to something without knowing, or caring, what exactly it is or how it works.

I'm sorry that I long ago coined the term "objects" for this topic because it gets many people to focus on the lesser idea. The big idea is "messaging"

Alan Kay

Many just use the word "polymorphism" to speak to this point but that focuses on the thing having many forms and not the portability of the message.

That might seem like a bunch of nonsense. The code doesn't care what you focus on. So lets say it a little more formally.

The mechanism of polymorphism must not create a source code dependency from the caller to the callee.

Uncle Bob

OOP lets you ignore what you're talking to and only insist that, whatever it is, it understands the mini language you use to talk to it. Working that way lets you erect firewalls against the impact of change. You can dive in and rework this kind of code and not have to watch a design choice change spread through the code base.

OOP is not a kind of language. It's a programming style. Any "OOP language" can be defeated in hands of a procedural programer. Many general purpose languages, that have never heard of OOP, are flexible enough to allow you to use OOP if you insist on it.

Inheritance (a form of polymorphism) and encapsulation (true state hiding, not just stupid getters) both exist in "non OOP languages" like C and can be found in procedural code. So while those are nice tools they really aren't tools unique to OOP.

No, the one thing that is OOP's killer feature is the ability to communicate without knowing what you're talking to. If it changes, why should you care? You just keep talking.


Polymorphism, encapsulation, and inheritance are the traditional advantages of OOP. They can of course be done in non-OOP languages, but they are made easier in languages designed for it.

You can make "classes" in C, but it's a pain to do it. You can make polymorphic functions in scheme, but you have to find an external library. You can get the effects of private fields in JavaScript, but you have to understand closures, constructors, and this.

In a more object-oriented language like C# or Ruby, making a class is as simple as using the class keyword. Encapsulation is as easy as using private. There are built-in structures for inheritance, and you can know that dispatch is only ever dependent on the first variable.

Getting more subjective, I find it easier to organize my code when I have more levels of grouping. In C#, I make a class for each group of functions that do similar things or manipulate the same state. I can then make a namespace to group classes together, and projects to group namespaces together. And, I can have the compiler complain if I try to access something in the wrong place.

Modules do something similar for functional languages, but they are often the only level of grouping. You can recreate namespaces and classes with closures, but IDEs aren't usually built for that. Compared to writing myObject. and looking at the autocomplete options, opening a different file to dig around nested closures to find what I want is a pain. It's even worse if you don't have the source and have to rely on external documentation.

In pretty much any modern programming language you can accomplish the same stuff. I can emulate objects with closures and emulate closures with objects. But I find it a lot nicer to read x => x + 1 and class File { read() { ... } write(value) { ... } than class AddOne { execute(x) { x + 1 } } or file = (method, arguments) => (if (method == 'read') ... else if (method == write) ...).

  • 3
    Class-based OOP isn't the only kind. And not all of the bullet-points are covered in all languages considered object-oriented, or supporting OOP. Commented Jul 20, 2018 at 23:20

You are correct that Polymorphism - is the killer feature of OOP. But though there are quite a few other ways to achieve polymorphism (e.g templates, macros, message passing, etc), object oriented programming provides for polymorphism in a human-accessible form.

Remember - most programmers are human, and their ability to reason is very much tied to their genetic ancestry and how we evolved. Thinking about physical objects is the basis of abstraction (think about how kids learn math, counting on their fingers, counting apples).

Object-centered programming (or modeling) is modeling data as objects. This by itself is wildly useful (and is the basis of data hiding abstractions and so on).

But polymorphism is the basis of concepts like interfaces, and is fundamental to how people reason about modularity (and so fundamental to how they build larger systems).

What makes OOP tick is the combination of object-centered (human intuitive) modeling, with polymorphism: presenting the polymoprhism in an already human intuitive way. People just started with mental machinery to treat classes of objects uniformly (e.g. avoid big scary animals).

My $0.02...

  • "their ability to reason is very much tied to their genetic ancestry". Lol, wut? I'm not sure what you're trying to say, but that sentence sounds very much like the specious arguments of eugenicists and racists. I presume that's not what you meant? Perhaps rephrasing it would make it more clear? Commented Jul 21, 2018 at 0:47
  • 1
    You doubt that how people's brains work is an inherited trait?Do you think its coincidence that people think similarly? And that techniques used to teach one child might also work in teaching a second? I never mentioned the word 'race'. That you made that connection - I believe - says more about you than me. Commented Jul 21, 2018 at 1:26
  • What it says about me is that I've been on the internet where that exact wording is used by many racists to make a pseudoscientific point about race and intelligence. If that's not what you intended and you want others to understand what you meant, you should consider changing the wording to be more clear. Commented Jul 21, 2018 at 1:40
  • Some people will see what they want to see. I offer a free service - answering questions. I made a good effort to be clear and helpful. If you think I've failed, vote down my response and move on. I have re-read my comment. I cannot say its the most clear thing I've ever written. Actually - the part I really struggled with what the last paragraph (not counting my $0.02). If you thought the rest was unclear, or wrong, or inflamatory, do what you think is best. I hope you are earnest in your beliefs, and I'm ready to move on. Commented Jul 21, 2018 at 1:44

The killer feature of OOP is controlling access to data.

The binding between the data and the code used to manipulate that data provides the capability to control how that data is used and safely mutated.

  • 1
    What you describe is Data Abstraction. There are two different kinds of Data Abstraction currently in widespread use: Abstract Data Types and Objects. Your answer doesn't explain why OOP would be needed since everything you say in your answer applies equally to ADTs. Commented Jul 21, 2018 at 9:59
  • @JörgWMittag, the question is what is the killer feature of OOP and not to explain 'why OOP would be needed'. Encapsulated data and code is what an object is, allowing the other 2 legs of OOP, inheritance and polymorphism to stand on.
    – hocho
    Commented Jul 21, 2018 at 21:01

The same comparison can be made IRL:

  • directly constructing a building with no plan VS
  • letting an architect draw up a "blueprint" (= class) and letting the construction workers build it (= instantiation and usage, as many times as needed)

OOP offers more than that. Basically, you bundle together domain data and restrict access (encapsulation), offer it as a blueprint (class) and define its behaviour through methods so one can build (instantiate) as many such "objects".

If you want scalability, you need OOP. You cannot build a city or a country just by going at it without any planning. You need to map everything out, plan it properly, come up with the blueprints of houses you wanna use, perhaps even reuse some good blueprints from other engineers, ...

And more than that, you can automate the building process to various degrees through abstraction - there are factories that take blueprints and spit out objects. If you wanna create a 3d modell object, you can do so with 3d printers. Thats just a small example. You provide the blueprint (3d data, your "class") and the printer brings it into existence. You can reprint it as many times as you wish. People can take your 3d object (blueprint, class) and extend it (inheritance, polymorphism)... All those extension are of the same type, it is from your original 3d modell. So to some certain extent, they can be treated as that.

Perhaps this is a bit too abstract but imagine another case: You design the most generic "vehicle". Then comes along Joe, takes your design / blueprint / class, extends it and calls it "car". Michelle does something similiar and calls it "bike".

Both are vehicles. Both provide you the general functionality of a "vehicle" because both are, they extend it. So then you can be agnostic about what type of real object you are dealing with, treat them simply as "vehicles" and apply logic to them that works with "vehicles". You dont need to differentiate between Car & Bike because the business logic you are going to apply does not require you to do so!

A vehicle painting factory does not care whether its a Car or a bike. They can paint both... So many examples!

Edit Sorry for rambling, hope you got the point though!

  • 1
    I think your argument is off. You can have factories in C, too, and its not that troublesome (e.g. fopen("someFile") vs. (new URI("file://someFile")).open()). I agree more with Andrew in that the language support (mainly type-checking and syntax) cuts the deal.
    – marstato
    Commented Jul 20, 2018 at 23:15
  • 1
    Well I tried...
    – Aphton
    Commented Jul 21, 2018 at 0:56

Not the answer you're looking for? Browse other questions tagged or ask your own question.