There are so many definitions of OOP out there, varying between different books, documentation and articles.
What really defines OOP?
Submitted 9 months ago by matcha_addict@lemy.lol to programming@programming.dev
There are so many definitions of OOP out there, varying between different books, documentation and articles.
What really defines OOP?
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?
Once upon a time, “big data” was datasets large enough that it was impractical to try to store or work with them in a traditional relational database software. Which is where distributed storage structures came into play with the ability to spread both storage and computation across clusters of machines, using solutions like Hadoop and MongoDB. That seemed to be the direction things were heading 10 - 15 years ago.
However, with the automated scaling built into modern cloud databases, the line has gotten a bit blurry; Snowflake, Redshift, BigQuery all handle many billions of rows just fine. I probably wouldn’t use the term big data in a professional context these days, but there is a table size after which I write code a bit more carefully.
I suppose my point is that the term once meant something, but marketing stole it because it sounds cool. I worked in a tech shop in the late aughts where the sales team insisted on calling every rack mounted server a “blade server”, regardless of whether it had modular swappable boards. Because it sounded cool.
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.
That’s all of CS and IT.
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!
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:
dict_add(foo_dict, key, val) # OOP semantics foo_dict.add(key, val) # OOP syntax
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].
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.
As originally envisioned, objects were supposed to communicate by message passing: i.e. there would be a separate thread of execution for each objects, 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.
There aren’t really that many definitions for OOP; it’s a very consolidated paradigm. This is a short but comprehensive guide: www.baeldung.com/java-oop
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: 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: 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.
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.
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 put object 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.)
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 that really is about completly different things.
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.
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.
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.
Using objects to represent data.
Does it really matter? This knowledge won’t help you in writing code.
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 become clearer when you have your own understanding and opinion about it.
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.
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 gury 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.
HyonoKo@lemmy.ml 9 months ago
Instead of making one big mess, you make multiple smaller messes and stuff them into objects.
MajorHavoc@programming.dev 9 months ago
Yep. State is bad, so in OOP we take the huge uy ball of unnecessary state, and we spread it across the program ecosystem as a thin ugly brittle venier of unnecessary state.
Hexarei@programming.dev 9 months ago
Let’s just not talk about the part where the computer is inherently stateful though 😉