What is OOP, really? Why so many different definitions?
There are so many definitions of OOP out there, varying between different books, documentation and articles.
What really defines OOP?
There are so many definitions of OOP out there, varying between different books, documentation and articles.
What really defines OOP?
Instead of making one big mess, you make multiple smaller messes and stuff them into objects.
Yep. State is bad, so in OOP we take the huge ugly ball of unnecessary state, and we spread it across the program ecosystem as a thin ugly brittle venier of unnecessary state.
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
keeping state (data) and behavior (functions) that operate on that state, together
Importantly, that's "together at runtime", not in terms of code organization. One of the important things about an object is that it has dynamic dispatch. Your object is a pointer both to the data itself and to the implementation that works on that data.
There's a similar idea that's a bit different that you see in Haskell, Scala, and Rust - what Haskell calls type classes. Rust gives it a veneer of OO syntax, but the semantics themselves are interestingly different.
In particular, the key of type classes is keeping data and behavior separate. The language itself is responsible for automagically passing in the behavior.
So in Scala, you could do something like
def sum[A](values: List[A])(implicit numDict: Num[A]) = values.fold(numDict.+)(numDict.zero)
Or
def sum[A: Num](values: List[A]) = values.fold(_ + _)(zero)
Given a Num typeclass that encapsulates numeric operations. There's a few important differences:
All of the items of that list have to be the same type of number - they're all Ints or all Doubles or something
It's a list of primitive numbers and the implementation is kept separate - no need for boxing and unboxing.
Even if that list is empty, you still have access to the implementation, so you can return a type-appropriate zero value
Generic types can conditionally implement a typeclass. For example, you can make an Eq instance for List[A] if A has an Eq instance. So you can compare List[Int] for equality, but not List[Int => Int].
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?
datasets large enough that it was impractical to try to store or work with them in a traditional relational database software
How I remember it is that it's not even the whole dataset that is too large, but the individual records. Hadoop for example is not doing anything magic, it's just a software package to extend MySQL to be able to efficiently have pictures (Facebook's original use case, of course it evolved) as records.
I guess big data is what you need it to justify what you want to justify. In one of my gigs' case, it was public funding for a project.
Yeah that’s a fair point, I was dealing with some records that had several 128 bit string columns recently, and it was tougher to process efficiently than a table several times its size made up of ints and bools.
Hadoop was based on MapReduce, and really just provided a framework for distributing storage and processing, there was no actual semantic layer to interact with it built in. It was a pretty foreign land for a SQL Server/Oracle admin. Hive was the data warehousing module on top of Hadoop that added HiveQL for interacting with it in a SQL like way, Spark and SparkSQL/PySpark were popular as well. It really did seem kind of magical at the time, NoSQL was a buzzword there for a while.
For example, what the hell is big data?
Big data is when we align our agile synergies at scale.
Wait, so, the Cloud is actually just a bunch of other computers, called servers, and the only real innovation is basically a load balancing system?
Next youre gonna tell me I wont be able to stream lagless video games and also do competitive multiplayer on my Google Stadia, pff, like youre some kind of expert or something.
/s
I wont be able to stream lagless video games and also do competitive multiplayer on my Google Stadia
Negative latency!
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.)
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.
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
the comments in this thread show that there are different answers to the question, including different from this post.
Nonetheless, I appreciate the link. It's a good read.
It's simply not true that there "aren't really that many definitions of OOP", much less that the guide you've linked is "comprehensive" when it is specifically about Java.
This is a good, brief post about the different conflicting definitions: https://paulgraham.com/reesoo.html
This is a much more comprehensive but also less focused overview, with many links, from a site that is effectively both a wiki and a forum: https://wiki.c2.com/?ReesOnObjectOrientedFeatures
Academically, you're right. For practical reasons, you probably don't care how Simula, E, Lisp and Smalltalk (languages mentioned in that 20 year old article) implement it. This seemed more like a beginner question so I think the Java definition is a good starting point.
Alright, I commented a quip/anecdote in a thread below, because I figured this was an easy answer that didn’t need another piling on, but I’m not happy with any of the answers so far.
OOP is, at its core, representing a data structure as an object.
For example you may have a Customer, and that customer may have properties such as their id, their name, their revenue.
So instead of passing those properties as a tuple or list, you can first define that object, and then construct new instances of the object that store each property, that can be passed and accessed as a single variable.
The magic of OOP really comes in when you get into inheritance. Imagine you have two types of customers, one needs to represent id, name, revenue; the other needs to represent id, name, debt.
You could add a debt property to your original Customer object and reuse it (probably more practical in this case) but as an example,
Or, you could define a Customer object with the properties id and name, and then define a CurrentCustomer object inheriting from Customer, which forces you to implement id and name, and then you can extend it to include Revenue. Likewise for the OverdueCustomer object, inherit from Customer, implement the id and name required by the parent, and then add the Debt property.
That then allows you to write a method that accepts a Customer variable that could work with a CurrentCustomer or OverdueCustomer object, since they’re both inherited from Customer they can be passed as Customer types. And that method then implements logic to determine whether we should forward to standard billing or collections. Since both objects descend from Customer, we know that id and name will always exist, and we can use if/case statements to determine from there.
Now think about that in terms of what you can force inheritance of. You could create a DatabaseConnection object, which forces the implementation of not only the database_name property, but also the ExecuteQuery method. Each implementation then needs to define how they connect to their own database instance. Now we can create objects that connect to either Snowflake or SQL Server using the same syntax.
This is generally how APIs are implemented, the parent library tells you what you need to implement to construct objects that will work with their methods, and once you inherit that and construct a version of the object, you can pass that as if it’s native to the original library.
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.
Javascript is generally considered OOP, but classes weren't widely available till 2017.
Inheritance isn't fundamental to OOP, and neither are interfaces. You can have a duck- typed OOP language without inheritance, although I don't know of any off the top of my head.
Honestly, the more fundamental thing about OOP is that it's a programming style built around objects. Sometimes OO languages are class based, or duck typing based, etc. But you'll always have your data carrying around it's behavior at runtime.
JavaScript has been OOP since I can remember due to its prototypal nature. Change something on an inherited prototype, and every descendant also get those changes. And "classes" is just syntax sugar for that prototype mechanism.
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.
OOP is one of, if not the most popular programming paradigm. Surely understanding it at a theoretical level isn't useless. It would be the first step to understanding its benefits and trade offs.
Use it for a while, to complement your theoretical study. Things will only become clearer when you have your own understanding and opinion about it.
You are right. But I still find the 'heavier' theory, that is what I assumed OP refered to, to be more difficult to grasp then following a basic tutorial and just trying to solve problems. In time with practice you get a better understanding for WHY the theory is how it is, and you can apply it better and of course improve your code. And that understanding will unlock more tools both in OOP and in your mind.
So if you are struggling, I recommend not starting with theory.
I see where you're coming from, I think. In my experiences with trying to follow tutorials though, I've found the difficulty to be between rough explanations and the examples given feeling a little too simple and isolated from how they might be applied in a working program.
Yes, and often incomplete or not maintained.
Anyway, OP read different sources about OOP and still needs to ask the definition... At some point it is better to just do something than to keep banging your head at the theory. If learning to code is your endgoal
Theoretical level is useless, believe me. What is useful is understanding at intuitive level. You can achieve it with or without knowing theory, but you need a lot of practice anyway. Also, different languages providing OOP actually encourage different approaches. You have to follow one that your PL is suited to and that is the best solution for your current task, not that OOP or any other paradigm dictates you.