Programming

Instead of making one big mess, you make multiple smaller messes and stuff them into objects.

OOP is when you forget the S by mistake.

Dude, you're going to shit bricks when you realize most computer science jargon is just marketing buzzwords on top of marketing buzzwords and the terms never meant anything more or less it needed to sell a product.

For example, what the hell is big data? What is a scripting language? Is your DB web scale?

You're getting a lot of conceptual definitions, but mechanically, it's just:

keeping state (data) and behavior (functions) that operate on that state, together

At minimum, that's it. All the other things (encapsulation, message passing, inheritance, etc) are for solidifying that concept further or for extending the paradigm with features.

For example, you can express OOP semantics without OOP syntax:

foo_dict.add(key, val)  # OOP syntax

dict_add(foo_dict, key, val)  # OOP semantics

OOP on its most fundamental level is the principle that stuff is represented by objects and those objects communicate with each other. That's it, that's the whole OOP.

What you are probably referring to is how OOP solves different problems and the different patterns it uses. Those are not OOP itself, those are basically instructions on how to do OOP correctly without shooting yourself in the foot.

So SOLID, IoC, dependency injection, factory, composition over inheritance and all the other famous principles are not OOP itself, but any medium-size app that's not following them is set for really fun times ~5 years down the road.

Not sure if I've answered your question, it's really vague, feel free to ask further.

The Haskell world (which admittedly is its own type of crazy) considers OOP to be a 1990's thing that was well-intentioned but didn't work out. The basic characteristics of OOP are subtyping and inheritance (added: plus stateful objects).

As originally envisioned, objects were supposed to communicate by message passing: i.e. there would be a separate thread of execution for each object, so they could do stuff asynchronously to each other. By that notion, Erlang is the only OOP language that has any traction. Joe Armstrong, inventor of Erlang, famously said:

I think the lack of reusability comes in object-oriented languages, not functional languages. Because the problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.

He could have fooled me. I would have guessed he was talking about npm ;).

Ok, so in most languages, you have some way to define a data structure. It could be anything. Maybe it stores the X and Y coordinates of a Cartesian vector. And now you want to do stuff with your vectors, so you write a bunch of functions you can call like get_vector_length(myvect) or add_vectors(vect1, vect2).

In OOP, you add that kind of functionality into the data structure itself. So now you can just write myvect.length() or vect1 + vect2 (by implementing the + operator for your data structure). At this point, the data structure is typically called a "class" and the functions you build into the class are "methods".

As you dig deeper into it, you learn about inheritance. When you have 2 related classes that share a lot of functionality, you can use inheritance to save a lot of duplication in your code.

In statically-typed languages, it can also come in useful to have a base class you can pack into a container, since most containers can only accept a single data type. If you had some graphics classes like Rectangle and Circle that all inherit from Shape, you could make a collection of Shape that's a mix of those. (In dynamically-typed languages, this tends to be less of an issue since you can put objects of any data type straight into the list. This might be why OOP isn't approached as soon in tutorials for such languages, since it's not as mission-critical? But it's still a good idea to have some sort of class hierarchy where it makes sense.)

There aren't really that many definitions for OOP; it's a very consolidated paradigm. This is a short but comprehensive guide: https://www.baeldung.com/java-oop

It's the sound a Mid-Westerner makes when they're trying to get past you.

But for real, it's because this was super common:

typedef struct {
   // data structure
} SomeDataStruct;

void SomeFunction(SomeDataStruct * data) {
  // lots of functions like this
}

Like many things, once OOP became a thing, people started adding to it. This is why you get a ton of different definitions and such.

Which OOP? Alan Kay meant this:

OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them.

But there is also various other OOP around. And those really about completly different things.

What kind of different defintions have you came across?

In Essence, OOP: you describe with your code Classes and how those classed Objects interact with each other. Classes can be inherited from other Classes and or implement Interfaces (Interface, Traits, Protocol) so you know how derived classes can be interacted with even though you don't know the concrete class until runtime execution.

The tradeoff would be the stringent nature of OOP: you need to have Objects, otherwise it's just functional/procedural programming with extra steps.

It's similar to any tech buzzword. Take "agile" for example. Agile was successfully sold as being a great idea without really being well-defined. Suddenly anyone selling a development methodology had a strong incentive to pitch it as being the real way to do agile development.

In the 90s and 2000s every 10x california tech guru agreed that OO was the future, but apparently none of them actually liked smalltalk. Instead, every new language with a hint of dynamic dispatch suddenly claimed to represent the truest virtues of OO.

There are also people who argue that smalltalk is not true OO. They say that by Alan Kay's own definition the most OO language is Erlang.

I think it's most useful to learn about that history, instead of worrying about people's post-hoc academic definitions.

Using objects to represent data.