Is it true that classes are only used by programmers that have no class?

Yeah, I know that, but why? What's the point?

To not accidentally modify them and to make program execute some other code every time the values are accessed if wanted

Imagine a rectangle
Area is a property for efficiency, but is actually calculated when you set the width or height of the rectangle
So you want to getArea(), but you never want to do area=5 except inside the class code.

>To not accidentally modify them
But what if you accidentally call the setter
>and to make program execute some other code every time the values are accessed if wanted
This is a good reason but for that matter why bother using getters and setters unless you need getting and setting to do something extra

I do it just in case but then again I'm a fucking casual.

No, but programmers who are employeed

Accidentally calling setter is a lot harder to do than messing up with raw variables

>why bother using getters and setters unless you need getting and setting to do something extra
Java (and enterprise code) are based around this idea of "being ready for future changes". So when Joe McFuck the Jr developer triest to fuck with the code, he does it in a way that is mantainable and won't lead to manually doing "find replace .x -> .getX() if object is "
But honestly it's just stupid that it isn't a language feature like in C#, where you can simply "overload" the .property operation.

the point is to keep the other 100s of programmers working on the same codebase from messing with your shit

Ahahahahahaha

but, you were just going to set or get them anyway, right?
so, what does it matter?

What do you do when you have a list in the class? Are you meant to have methods for every operation the list can perform?

There's circumstances when there is a point but people love to think it's the default way you should do it.
The only excuse I can imagine for doing this prematurely is that its part on an exposed interface or that you're working in a dynamic language and have no hope of statically analyzing your code for a change to getter/setter usage.

By controlling how other classes or code interact with that attribute you shrink complexity and make your code more organized in general. This way you ensure that other classes are also not modifying data when you're not expecting or explicitly allowing them to unless through a designated procedure from the class rather then their own

Couldn't the list be its own class and just be an attribute of the class using it, and when you need to perform list operations you just use the operations of the list's class itself?

It's a simple and logical way of grouping data and the methods that operate on them. What's wrong with it?

Class.getList().append(new)

Let me just also add that none of these things are apparent in a really small example shown like this for OOP. This is why OOP approaches really only shine in big projects where object-based organization can help reduce complexity and allow for particular coding patterns and structures that allow for greater extensibility while maintaining clarity

Doesn't this break encapsulation?
What if I want clients to read the list, but not write to it? Should I implement by own getter for list.length as well?

I'm unfamiliar with the term attribute.

attribute is just anything that is not a method in a class basically, like an int or a string for a class. basically just any data a class holds of any type that doesn't perform any additional instructions. What I was basically saying is just use the methods of the list rather than making methods for the class holding the list.

>What if I want clients to read the list, but not write to it?
Yes you can do that if you want. By having a method to read but none to write to it.
>Should I implement by own getter for list.length as well?
If you want.

What kind of programming do you do taht you don't even know what an attribute is?

Re-creating the interface for a list seems incredibly tedious. Surely this can't be the OOP way.

>What kind of programming do you do taht you don't even know what an attribute is?
I'd just say "member" or "field".

yes

>Tfw you never had a problem getting this shit
>Tfw don't even have a CS degree
>Tfw working in the field
Brainlets

Attached: 03B24A33-17DD-4785-8A6D-065238D540E6.png (172x172, 51K)

Thing thing;

Thing getThing(){
return thing;
}

void setThing(Thing thing){
this.thing = thing;
}

Attached: disgusted pepe.png (218x218, 64K)

same bro, strawberry or rice?

Yeah, in such a case in which you are straight up getting/setting the thing with no conditionals or extra procesess whatsoever, why not just making the thing fucking public?

Because these faggots are code monkeys that never write any actual production code, and fail to understand the underlying reason for why certain code is desirable and just mindlessly follow "proper style" even when it makes more sense because they were told encapsulation is good. While it's true, it has a time and place. It's just as fucking dumb as arguing that functional/OO/Procedural programming is a silver bullet and everyone should use one paradigm exclusively. Clearly you should use the pattern that best solves your problem while keeping a sane architecture. I was recently debugging code of a brainlet that argued every noun in a problem description should be it's own class and treated as such, even when some are better represented as functions/properties of other objects just because in OOP "You're supposed to abstract everything into classes". It's fucking stupid. If you have a bank account, a balance, and a transaction you have an account object with a balance property and a transaction function. fucking brainlets.

classes are for cucks. 9 times out of 10 you don't need them

Your example is too simple to be useful. Imagine a class requires the list to be in a specific format. Then it will abstract the list away using member functions that keep the list in its specific format.

As a dumb example you could have an emailAddress class that allows you to modify the address on the fly. It's all just text manipulation, but you wouldn't give the user access to the underlying string. You would provide functions like changeAddress or changeDomain.

The only valid reason for having getShit and setShit over just a .shit on your Widget class is if you expect to need to create a NetworkWidget or a SQLWidget that drops in and uses the same API. If you've already hardcoded a bunch of direct access, it'll be a nightmare to refactor, because SQLWidget needs to actually do something to pull the value of .shit from a database. That's what getShit is for.

If your class is going to be POD and always be POD, just leave it POD. Don't be one of those fuckers that has getX, setX, getY, and setY on their fucking Vector2 class.