What's the actual point of classes?

What's the actual point of classes?
Why would you want your data and functions in the same place???

Attached: badass.jpg (1486x1022, 261K)

Other urls found in this thread:

gigamonkeys.com/book/object-reorientation-generic-functions.html
gigamonkeys.com/book/object-reorientation-classes.html
twitter.com/AnonBabble

is that a photo of /csg/

The point of classes is to have reusable interfaces that can be instanced at will. They are an abstraction and a part of a paradigm. It's not set in stone, you can use whatever but it's good to be well versed in it nonetheless

>"classes are useless!"
>pre_fixes all his function with the name of the struct to invoke them with
Although I agree that going too far and creating a full blown inheritance hierarchy together with meme patterns amd the like is insanity.

So that you can reuse code by encapsulating blocks of functionality. It's the principal of OOP.

Encapsulate state.

Classes are like monads, really.

Why would I reuse code?

Do you throw away your plate after you're done eating or do you re-use it for ease of access? Don't tell me you use plastic plates now. That's not what this question is about.

I don't program plates!

Then how come your code looks like spaghetti?

kek

>you can't reuse normal functions
This is that OOP retards actually believe.

lol

Attached: 1537546149653.jpg (1656x1532, 60K)

There are object systems that separate methods from classes. In such systems, methods are part of a generic function that can operate on different classes.
CLOS of Common Lisp is such a system. You can read an introduction to it here, from the free Practical Common Lisp book:
gigamonkeys.com/book/object-reorientation-generic-functions.html
gigamonkeys.com/book/object-reorientation-classes.html

i am also new but classes are mainly used for protecting data.
for example you are working on a big project you wrote functions and have some global variables. These identifiers (variables) can't be use in other part of code which other co-workers are working on so it avoids conflict.
Also it is provides some nice features for more re usability.
In language like C
you call a function fun(other_fun(), arg1, arg2) this can be confusing but when using oop
your can do ofun.fun(arg1, arg2) where ofun is instance of otherfun class which is more easier to work with.
If you are doing and simple project where only you mange it you know what you have done but when working with others you don't disturb other's stuff and work on your own.

The main point, and the most overlooked one, is that it forces a certain structure upon the code which, in theory, makes it easier to maintain. (Kind of like significant whitespace in Python forces you to indent your code.)
In practice, the nature yet again invented a better idiot, and overzealous use of OOP features and design patterns is turning large codebases into huge, clunky monoliths of overdesigned shit.
The morale of the story being that everything has to be taken in moderation, and that no amount of clever tricks will save you from the forces of utmost stupidity.

I never understand these threads.

There's nothing wrong with OOP. The only two things that matter at all are

1) Does it work?
2) Are the people who have to deal with the code able to read and understand it?

>1) Does it work?
no
>2) Are the people who have to deal with the code able to read and understand it?
no

Classes are a definitives of themselves.
Functions are recipes to perform.
Pointers provide the ingredients to a directed place it is stored.

As someone who works professionally with OOP I don't really think classes solve any sort of problem that can't be solved with static functions.

Instance methods are mostly just a way to invoke static functions using an infix notation and with the data you're modifying as an implicit first argument (and the lack of infix notation for regular function invocation is just a matter of most C-like languages being poorly designed).
And if you want to support virtual/overridable methods (which you almost never do) you could just use a function pointer.

From my experience, real world classes fall into two categories:
1. Glorified C structs with getters and setters
2. Byzantine messes which break all the rules of OOP design.

I mostly use the former, as its more straightforward to just pass around an object as a ball of state then try to implement the dispatch pasta that most OOP text books consider good design.

>1. Glorified C structs with getters and setters

getters and setters, also known as: why and why

I know its supposed to help you not overwrite important data. But a setter doesn't help you. its just an extra step before you fuck your shit up

Functions are useless without data to operate on. Data is useless without functions to operate on it. Pairing them together is natural.

neither of those statements are even mostly correct :^)

Setters are cool for when you have to perform some sort of validation or something on the value passed.

> Poop.SetStatus("pee");
TypeError: Invalid Status "pee"
> Poop.SetStatus("diarrhea");
null

of course Set functions are gay, you'd rather just have real setters so you could just set Poop.Status = "diarrehea"; or something.

Based user btfo JUSTnon

Attached: justnon.png (108x71, 8K)

Wrong, they are mostly correct statements.