If you find a programmer that uses getters() and setters() without any complex logic inside them, you should burn him/her/whatev with the strength of a thousand suns.

Lol why?

@phat-lasagna because it is unnecessary abstraction then.

Don't judge too fast.
- If you don't have readonly in your language you usr private variables and getters.
- if you don't have type hintings for properties but for function Returns only (as in php 7), you use getters.
- if you want your class too be extendable with complex logic in the getters and setters - you need to implement them.

There will be more examples.

This is what I thought until I learned why they usually should be there

I mean it's only dumb IF both getter and setter of the same member contain bare boilerplate. Like in cases where programmer tries to mimic access control in a language that was not designed for it.

Yes, *that* is dumb.

@aviophile Yeah I get your point, but I have mainly seen their benefit in 1) inheritance and 2) enforcing the private member OOP design. Otherwise people will just make members public Willy-Nilly and most of us know how that can go. (I guess this is only applicable to languages that are setup for good ol OOP)

Sir, that’s the purpose of getters and setters. ENCAPSULATION bro!!!

Don't worry, you'll grow into it :)

Let's write ALL business logic inside getters then! 😈

well I'm literally just sitting in front of a:

std::string getSomethingSomethingSomethingErrorMsg()
{
return "error"
}

is this bad?

@arcioneo @phat-lasagna what' the point of having a private member with a simple get() {return $this->mem} and set($mem){$this->$mem = $mem} when making It public does exactly the same thing.

Depends on the language I guess.

But still, if you have a complex get/setter, it's probably doing too much.

@PonySlaystation challenge accepted

@Jedidja it's cpp i suppose, so it's bad by definition

But now serious question, as I read about this in the Google code styleguide.

What if the private object is set within the class (multiple times during the runtime), so it's reference may change and you don't want it to be set from outside?

So private prop, get prop() with a simple return, but no set.
Allowed? If no, what's the suggested design for this?

@phat-lasagna if it is going to be public, just ignore getter. I have never seen public attribute had to have public getter method down in inheritance line. Also, inheritance is overrated and is not necessarily part of oop.

@aviophile How is inheritance overrated?

@PonySlaystation this is giving me flashbacks to the shit project that had hundreds of lines in getters.

@PonySlaystation justification of reuse of code is extremely contextual and heavily overblown. When we were in university, it was also advertised as part of core oop which is a lie. Compositionis almost always better anyways.

They even teach these shit practices in uni:

Always make getters and setters for class members.

Always write 10 lines of doc comment for each single method, explaining every single parameter and return value

Always make a subclass if you want to reuse code.

😣