What exactly is the point of OOP? As far as I can tell, an object is just a blob of data with some associated functions...

What exactly is the point of OOP? As far as I can tell, an object is just a blob of data with some associated functions. The difference between foo(obj, arg) and obj.foo(arg) is purely syntactic, so what's the conceptual difference between an object, and a data structure + a set of functions that mung it?

Other urls found in this thread:

wiki.c2.com/?AlanKaysDefinitionOfObjectOriented
wiki.haskell.org/OOP_vs_type_classes
wiki.haskell.org/Polymorphism
twitter.com/SFWRedditGifs

Inheritance and polymorphism.

>Inheritance and polymorphism.
So if you're not using that, your objects aren't real objects/you're not doing OOP?

Yeah. You're just using structs.

Yeah, except that polymorphism isn't unique to OOP and that inheritance is shit.

Don't use OOP, it's shit.

Polymorphism is in no way unique to OOP. Inheritance is, but OOP programmers are instructed to avoid it and to use composition instead. Are you sure those are the two things that make something object-oriented?

>Don't use OOP, it's shit.
I don't, but I'm not here to make value judgments about OOP. I just want to understand what the essence of "objects" is to OOP programmers.

I've no idea what you mean by "mung" so I can't answer your question.

There are many kinds of polymorphism though. I was talking about the stuff where a function with a base class argument also accepts every class derived from it, this also applies to collections. This requires vtables.

>I've no idea what you mean by "mung"
In this context it means mutating the object's internal state.

>a function with a base class argument also accepts every class derived from it
But you're talking about class-based OOP. There are OOP languages without classes.

The essence of objects to OOP programmers is encapsulation. It's mostly just a way to structure a program so as to separate implementation from interface.

It's just a way of designing your code that someone thought was a good idea sometime. Some languages have it built in. If you listen to Alan Kay you may find out that popular oop languages today aren't really the same as the original idea for oop. Have a look at pharo, learn about the Xerox alto and the features of the OS. Then wonder why we still don't have these features in modern OSs

>The essence of objects to OOP programmers is encapsulation
That's what I thought initially, but the average object in OOP-land has a whole bunch of setters. Encapsulation implies self-contained-ness. Most objects are not self-contained.

>a way to structure a program so as to separate implementation from interface
I don't see how this relates to objects.

Just another way to hide the state from the programmer. Any other use of provided mechanisms is heretical.

>If you listen to Alan Kay you may find out that popular oop languages today aren't really the same as the original idea for oop
Can you elaborate on what the "original idea for OOP" was? What's the essence of an object there?

>but the average object in OOP-land has a whole bunch of setters. Encapsulation implies self-contained-ness.
So what, though? Why does self-containedness imply constantness?

>I don't see how this relates to objects.
You can only access them from the outside using their public members, which then constitute their interface, whereas the implementation details are hidden with non-public members.

The point is to write as many lines as possible. Notice how FP-fags write everything in one line and have no jobs? Now you know why.

>Why does self-containedness imply constantness?
It doesn't, but if you find yourself writing getters and setters, it usually means that some other part of the program controls parts of the state of your object, so it's no longer self-contained.

That doesn't necessarily mean the object isn't self-contained. A class for describing 2D coordinates, for instance, can be self-contained even though it can be changed. Other code simply uses this encapsulation of 2D coordinates however they want.

>You can only access them from the outside using their public members
That just brings us back to functions and data structures, though (headers and opaque pointers).

Virtual functions and runtime polymorphism. Essentially just hidden function pointers.

>headers
How are you using that word here?

>opaque pointers
Yes, that's another method that is commonly used for encapsulation. Noone ever claimed that OOP brings new programmatic capabilities to the table (Turing-completeness &c&c). It basically just makes opaque pointers the ideological default.

SAS

>That doesn't necessarily mean the object isn't self-contained.
It does, because the object is no longer an independent unit. The semantics of its supposedly private fields are determined by external code. If you took at object and started to expose its private fields using getters and setters one by one, at what point does it cease being an object and become a glorified struct?

>A class for describing 2D coordinates, for instance, can be self-contained even though it can be changed.
What's the difference between a class for describing 2D coordinates and a struct?

Just another shitty "paradigm" for brainlets full of theoretical buzzwords, promising them a way to make their code fast, portable and maintainable, while those traits come from experience and intelligence of the user.
A good programmer uses the paradigm right for the job, he doesn't get told what he has to do.

Functional programming hype and the crusade against states are the same garbage, mind you

>How are you using that word here?
I was thinking of the separation of C code into .c (implementation) and .h (interface) files. Of course, this is just one of many ways to do it that don't involve OOP.

>It basically just makes opaque pointers the ideological default
My point is that separating interface and implementation (even as an "ideological default") is a principle that doesn't require the concept of an object at all.

>The difference between foo(obj, arg) and obj.foo(arg) is purely syntactic

the point of OOP is that it helps you reason about your software.

>the point of X is that it helps you reason about your software.
You can say that about any paradigm. What's the essence of objects that makes them conductive to reasoning about software?

Encapsulation

>at what point does it cease being an object and become a glorified struct
Implementation-wise, an object really *is* just a glorified struct, but that's not the point. The point is that you choose what getters and setters you add to a class in order to expose the behavior you want to expose. At what point it "ceases to be an object" depends entirely on the object you're trying to create. Why would you complain that, for instance, an object describing a configuration file has a setConfigurationDirective method?

>My point is that separating interface and implementation (even as an "ideological default") is a principle that doesn't require the concept of an object at all.
Conversely, you could argue that a properly designed opaque pointer is an object.

>Encapsulation
Feel free to give your input on this exchange about encapsulation:

In the end it's just a way to organize your code.

When you're working on a project with dozens of developers it gets harder and harder to keep track of everything. That's why when you get these enterprise projects with for example factory objects. It seems like too much indirection but when you can document the factory and the output objects then that's all the other developers need to know. They don't need to know what's happening inside.

Biggest team I was on was around 35 programmers and a huge code base. OO and some of the patterns that look funny on a small project were helpful.

>you choose what getters and setters you add to a class in order to expose the behavior you want to expose
As far as I understand it, the "behavior" of an object defines how its internal state should change in response to inputs. Getters and setters don't expose behaviors. They expose data, usually because the behavior (as far as the exposed fields are concerned) is defined outside of the object, thus it is no longer self-contained.

>At what point it "ceases to be an object" depends entirely on the object you're trying to create.
Is there a way in OOP-land to determine whether a particular instance of an object (in the technical sense) is an object in a meaningful sense? Surely you'll agree with me that taking a plain struct, turning it into a class and adding getters and setters for every field doesn't make it an object in any meaningful sense.

>Conversely, you could argue that a properly designed opaque pointer is an object.
How do you figure?

>What's the essence of objects that makes them conductive to reasoning about software?

Because then you can model them as interacting entities.

An object is a data structure with a set of functions to mung it. It's the same thing that you're describing about non-OO programming.

Some languages they're exactly the same. For example objective-c compilers (pre-compiles really) used to just produce c code and then compile that.

It's just a way to organize your code to make it easier to understand.

>Getters and setters don't expose behaviors.
That's not necessarily true. In the example of an object describing 2D coordinates, the data is all the behavior you want to expose. These are, of course, the more struct-like objects of a system, but isn't that all right? In the end, at the bottom of all algorithms, you always need to describe data.

That being said, of course, it could also be a sign of an improperly designed object. Naturally, there are bad programmers out there, regardless of whether you like the OOP ideology or not.

>Is there a way in OOP-land to determine whether a particular instance of an object (in the technical sense) is an object in a meaningful sense?
Not in any context-free sense. As above, it depends entirely on the behavior you wish to encapsulate. The way to evaluate how well that behavior has been encapsulated is, I'd posit, to compare the interface you just wrote to your mental conception of the behavior.

>How do you figure?
One might argue that if you're just using opaque pointers and behavior-like functions to interact with them, you're already writing object-oriented code, only in a language that wasn't explicitly designed for the purpose.

>you can model them as interacting entities
There are many cases where trying to model conceptual entities as objects in code only makes it harder to model the interactions between them. (Copious amounts of getters and setters usually indicate this sort of problem)

>That's not necessarily true.
It is necessarily true if you accept that the "behavior" of an object defines how its internal state should change in response to inputs. If you don't accept this, then please define "behavior". I can't really address the rest of your post because at this point I'm not sure what you mean.

>It is necessarily true if you accept that the "behavior" of an object defines how its internal state should change in response to inputs.
As I said, it isn't true if all the behavior you want to describe is a set of data, as in the 2D coordinate example.

I don't understand what it means for data to be behavior. Define "behavior".

Well, take a struct for instance, since they seem topical. The "behavior" of a struct is that it has members, whose contents can be used or changed. Modelling a struct in OOP would seem to imply writing getters and setters for each such member.

>There are many cases where trying to model conceptual entities as objects in code only makes it harder to model the interactions between them.

well then don't use OOP duh

The answer is encapsulation

>The "behavior" of a struct is that it has members
This doesn't make sense to me. I'm asking you for the third time to define "behavior". I think the behaviors of a struct are to read from a field or to write into a field on request, but we seem to disagree.

>well then don't use OOP duh
So what is OOP good for, again?

>The answer is encapsulation
Then why do you have to break it constantly using getters and setters in any non-toy program?

>I think the behaviors of a struct are to read from a field or to write into a field on request, but we seem to disagree.
Do we? That sounds like exactly the same thing I said.

>define "behavior"
I don't have a concise definition of it. Rather, I'm trying to make examples.

Situations where you don't want POD. No paradigm is absolute senpai.

>That sounds like exactly the same thing I said.
No. You said its behavior is "that it has members", which makes no sense to me. What I said is consistent with my definition, which you disagree with.

>I don't have a concise definition of it.
Then we've reached an impasse...

>Situations where you don't want POD.
That boils down to a tautology: "OOP is good when you don't want the opposite of it".

Not all data structures are pairs of coords. You're supposed to use the right tool for the job and encapsulation + abstraction can be very useful for modelling more complex behavoirs than setting and getting x and y.

But I don't.
Stop assuming that everyone misuses OOP like java pajeets does.

wiki.c2.com/?AlanKaysDefinitionOfObjectOriented

>But I don't.
So you don't use getters and setters?

That's all very vague, user. What I'm essentially asking you is this: what makes a good object? I'm not looking for abstract platitudes like "use the right tool for the job", but rather something more concrete.

>which you disagree with
Why are you contending that I disagree with you at the same time that you're saying that you don't understand what I'm saying? You wouldn't, by any chance, just be trying to be contentious, would you?

>Then we've reached an impasse...
To be fair, you haven't tried either.

>You said its behavior is "that it has members"
I said that it has members "whose contents can be used or changed", which seems consistent with what you said about "to read from a field or to write into a field on request".

>What I'm essentially asking you is this: what makes a good object?
That's like asking "what makes a good data structure". As I said in :
>Not in any context-free sense. As above, it depends entirely on the behavior you wish to encapsulate. The way to evaluate how well that behavior has been encapsulated is, I'd posit, to compare the interface you just wrote to your mental conception of the behavior.

The original idea was to have objects be separate entities when the program is running, and pass messages between them. So it was a late binding thing, not a static thing like how the mainstream ran with.

>why are you contending that I disagree with you
Because I said this:
>the "behavior" of an object defines how its internal state should change in response to inputs
And you said this:
>it isn't true if all the behavior you want to describe is a set of data

>you haven't tried either.
I've explained what I understand "behavior" to mean in this context. If it's not clear enough, I can give you something more detailed and definition-like.

>which seems consistent with what you said
The data is not the behavior, as far as I'm concerned. If you expose a data field through getters and setters, you are exposing data, not a behavior.

So basically, OOP programmers don't know what makes a good object? They just somehow "know" it when they see one?

>Because I said this:
>>the "behavior" of an object defines how its internal state should change in response to inputs
>And you said this:
>>it isn't true if all the behavior you want to describe is a set of data
Why are these contradictory? Calling a setter effects a change in internal state.

>The data is not the behavior, as far as I'm concerned.
Why not?

>The data is not the behavior, as far as I'm concerned.
All I'm saying is that what is "good" depends on what you're trying to do. I don't see why this should be controversial.

>to have objects be separate entities when the program is running, and pass messages between them
This has always been my understanding of it as well, but I can see why "mainstream languages" deviate from this: having true separate entities becomes increasingly harder as the interactions between them become more complex.

You're just acting obtuse at this point to try to make a point.

> having true separate entities becomes increasingly harder as the interactions between them become more complex.
That is just reality. FP which actually tries hard to be purely functional has an even bigger problem with this in real code than actual OOP does.

As is, you sometimes just have to compromise a bit on encapsulation to get the job done. Doesn't mean you get nothing from the remainder that you did encapsulate somewhat well, it does still make everything more manageable.

>>The data is not the behavior, as far as I'm concerned.
Fuck the clipboard. That quote was supposed to be >So basically, OOP programmers don't know what makes a good object?

>Why are these contradictory? Calling a setter effects a change in internal state.
I think the problem here is your struct example. You are conflating two different levels of abstraction: if you're talking about the abstract concept of a struct, then field I/O is a behavior. If you're talking about a concrete instance of a struct that is supposed to represent the internal data of some other kind of object, then it isn't.

Not at all. I am asking OOP programmers to explain to me the essence of an object. Can you tell me what makes a good object?

Whole reason for existence of oop is that not so fluent in compsci managers can still approximately get what is going on.

It is just a pure syntax difference. You can achieve the same results, the bloody same algorithms with and without oop.

>What's the difference between a class for describing 2D coordinates and a struct?
That you could have multiple classes for float, double or int coordinates all inheriting from the same interface?

>As is, you sometimes just have to compromise a bit on encapsulation to get the job done. Doesn't mean you get nothing from the remainder that you did encapsulate somewhat well, it does still make everything more manageable.
Right. It seems to me that in practice, most objects are "hybrid" in that they do have some actual private data, but also serve as a way to associate a conceptual entity with data that relates to it but isn't "owned" by it.

>Getters and setters don't expose behaviors. They expose data
What if a setter writes the changes made to the object into a log file or something like that?

You would still have different functions for each type being called, it's just syntactic sugar, nothing less, nothing more.

>that you could have multiple classes for float, double or int coordinates all inheriting from the same interface?
The same can be achieved more effectively using data structures and parametric polymorphism.

>if you're talking about the abstract concept of a struct[...]
Is this level of deconstruction really necessary? I just tried to make an example of when you want to represent pure data.

Well coordinates are a bad example for this
You could work with a single method, but with base-types the example doesn't work well

>What if a setter writes the changes made to the object into a log file or something like that?
I don't see how it changes anything.

wiki.haskell.org/OOP_vs_type_classes
wiki.haskell.org/Polymorphism

Not OO exclusive by any means.

>Is this level of deconstruction really necessary?
Yes, because it explains the root of your error. A data field is not a behavior, and on the level of abstraction we're talking about, getters and setters are just a means to expose data, not a means to expose a behavior.

>haskell

To the outside that behavior is completely invisible. Afaik you can't do that with a struct

>A data field is not a behavior
It has the behavior of being able to being read or written, and getters and setters expose that behavior.

>To the outside that behavior is completely invisible
Okay, the quote you're responding to goes:
>Getters and setters don't expose behaviors. They expose data
And your example still does just that, especially if logging something in the background isn't even part of the stated behavior of the object.

Your compiler still produces different functions. That doesn't change anything.

>It has the behavior of being able to being read or written, and getters and setters expose that behavior.
You're just making the same incorrect assertion again because you didn't understand my rebuttal.

The very core principal of OOP is programming to an interface - contractual behavior and data. Most of the other stuff eg "4 oop features" are kind of incidental, overlap other concepts, and are misunderstood by a large number of average software devs.

Most "OOP" languages are really multi-paradigm now anyway, even java is being slowly dragged into the current trend of functional programming.

What if the change of a value changes the objects name

>The very core principal of OOP is programming to an interface
This principle doesn't require objects in any way.

>what if the getters and setters do things besides being getters and setters
Then they're not getters and setters (at least not for the purpose of my argument).

Also most ITT don't really know what theyre talking about. Arguing about getters and setters is missing the point entirely and arguing about something trivial.

You're just insisting that objects cannot represent pure data, without saying why.

You can treat functions like an interface and it would work just as well. Why objects? Can anyone here give a good use case for objects?

> Arguing about getters and setters is missing the point entirely and arguing about something trivial.
Nice opinion. Too bad you didn't bother to substantiate it in any way or actually address any of the arguments.

Interfaces are THE core features of OOP - they allow inversion of control, encapsulation, polymorphism, and all the other goodies. Things like inheritence are the sideline features.

it was helpful because it allowed you to easily subdivide a complex problem into smaller, easily understandable pieces
but then someone invented design patterns and everything has been going downhill since

>You're just insisting that objects cannot represent pure data, without saying why
No. I'm saying that data fields are not behaviors, and exposing private data fields breaks encapsulation, whether you do it through a getters and setters or directly.

>Interfaces are THE core features of OOP
The principle of coding against an interface is in no way unique to OOP.

You can't treat functions as objects in a state-ful system. You are correct in a stateless system, which is a great ideal but OOP helps us manage state.

To the extent that what you want to model is a collection of data fields, why would you consider those fields private?