What is the "killer feature" of OOP? [closed]

Question

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?

Answer 1

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.

Answer 2

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) ...).

Answer 3

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...

Answer 4

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.

Answer 5

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!