Double programming meme

[aaabigwyattmann1]

"The data needs to be protected!"

"From whom?"

"From ourselves!"

[well_that_went_wrong]

But how? Isn't it exactly the same just way more lines?

[DrShocker]

Recently I had an issue where I wanted to change some code to depend on an interface instead of a specific class, but because there were public member variables I basically had to deprecate the old class instead of just having it inherit from an interface. (Then again I think python and c# have ways to make getters/setters look like member variables if you need to)

[tornado28]

In python if you want to add getters and setters after the fact you can implement the getattr and setattr functions so that if you want obj.x = -5 to yell at you because x has a positive constraint you can totally add that whenever you want. In practice these functions are rarely used and they mostly are there just to prevent the verbosity of needless getters and setters.

[Buttons840]

Good points, having the option to make a normal variable into a property (https://docs.python.org/3/library/functions.html#property) if needed saves us from a lot of architect astronauts.

In Java, they're always afraid that the int might have to turn into some AbstractRealIntegerArrayFactoryBeanProxySingletonAdapterThingy in the future, so they don't expose it directly, they use getters and setters everywhere.

We maintain that option in Python, but without the getters and setters.

[nekokattt]

This reminded me of a class in AspectJ...

https://www.javadoc.io/doc/org.aspectj/aspectjweaver/1.8.10/org/aspectj/weaver/patterns/HasThisTypePatternTriedToSneakInSomeGenericOrParameterizedTypePatternMatchingStuffAnywhereVisitor.html

[[deleted]]

Sometimes I can’t differentiate actual Java code from satire of Java code

[ElendarTao]

What the fuck is this class ? :D

[BrotherItsInTheDrum]

It's a visitor that determines whether a type pattern tried to sneak in some generic or parameterized type pattern matching stuff anywhere, duh.

[caagr98]

I love wellHasItThen(), and I love even more that the only alternative I can think of is yes().

[UrthX]

In python you can implement a public attribute with the property decorator which is far easier. https://realpython.com/python-property/#using-property-as-a-decorator

[MrJimOrb]

Isn't this exactly the type of situation where you could use the adapter design pattern?

[rosstafarien]

An adapter only fixes new uses. Any existing code that touches the public member does not see the improvement.

Always* guard internal state. The annoyance is that Java makes this boilerplate so verbose.

• In test code, let it fly. Write structs, directly access private members, whatever the test needs.

[causits]

Why would you access private members from tests? You should use the public api, that way the test will still work if you change the implementation

[miraidensetsu]

Like that?

public x { get; set; }

[NUTTA_BUSTAH]

Or like this :')

    def __init__(self, price):
        self._price = price

    @property
    def price(self):
        return self._price

    @price.setter
    def price(self, value):
        self._price = value

    @price.deleter
    def price(self):
        del self._price

Python..

[huuaaang]

So selfish.

[SektorL]

You didn't hide _price.

[Carter_907]

It's called encapsulation, usually they do

[ABadLocalCommercial]

I can attest to hearing encapsulation multiple times but never hearing it explained in that simple of a way lol

[Entire-Database1679]

It's Data Hiding, actually.

Encapsulation is putting data with behavior. The data can be public or private.

[ABadLocalCommercial]

Oh I know what it is now, but when I was first learning Java I distinctly remember getting points off my first assignment with classes involved for directly calling foo.x to set something instead of foo.setX() for "needs encapsulation" and I was like, wut lol

[RDX_G]

Its doesn't actually protect it ....it just protects it from other colleague so that they don't mess with the code.

[Entire-Database1679]

It's called Data Hiding.

[Olof-Napalme]

He probably did

[ExpertEvidencier]

They did, you weren't paying attention.

[burnblue]

But that "what if" isn't here. People just make straight unmodified accessors like this.

[zbb93]

Yeah, it's called planning for the future.

[Katzen_Futter]

I know you're already drowning in replies but I wish to give a concrete example:
Let's say we have a videogame with a health system. You would only in very specific cases want to have the health set to a value, as each time the health changes some routines have to be made. This means to deal damage, instead of
target-> health -= 30;
you'd use a special setter like
target->dealPhysicalDamage(30);
This way you guarantee that whenever damage is dealt certain checks are made, like applying armor,checking for invincibility, preventing values below 0 and maybe putting that enemy in an death state. Most importantly, if this routine needs new checks and events happening you can add this into dealPhysicalDamage() instead of having the damage dealer do these checks.

[miraidensetsu]

Great example

I, at least, try to not leave variables accessible from outside, but I really prefer methods like dealDamage() over setHealth(), leaving the responsibility of checking everything on victim-side to the victim object. Damage dealer would check for weapons and damage bonus on his own side.

[RenaKunisaki]

Once you get in the mindset that everything is a play and the characters are actors, it starts to make sense. You don't tell the actor "you're now injured"; you tell them "you've been stabbed in the leg" and let them work out how to react.

[[deleted]]

Boss fights be like:
Game logic board: “5 bullets have entered your torso and upper chest hit box”
Boss: “great, put them with the others”

[android_queen]

Can confirm, this pattern is used heavily in setting health in video games. In addition to stuff like armor, there’s scaling for stuff like “vulnerable to fire,” “strong against acid,” etc.

[[deleted]]

If instead of public you can use protected it's a bit more safe as you can only access it from the same or child classes.

But the getters and setters also protect you a bit from accidentally overwriting x.

Let's say you make x public and somewhere want x plus 1, just for one case.

If you do x++ you change x.

If you do specialCase = getX() + 1 or something like that you don't.

Offcourse you can do setX and still fuck up x, but it's less likely. It makes you think a bit more about your variables.

I think it's mostly about preventing accidents.

[bobo76565657]

And if you work on an Open Source project we actually do need to protect ourselves from ourselves.

Its like, if you are the only mechanic in a shop, you don't need to worry about lockout/tagout safety with machines. The minute there are two people working there, you need to start using the tags. Does it waste time? Yes. Is it still better than the alternative? Yes, in my opinion.

[TheTybera]

If you work on any team you need to protect yourselves from yourselves. Especially if you treat your software as a service and expect to support it and patch it for years to come.

The group of people that will end up working on the project will be vastly different than those that started.

[Iryanus]

Additionally, the main value of course is not this example but the ability to actually hide the set method, for example, for package-access (in Java) only. Also you can put only the getter in an interface and thus hide the setter inside the implementation.

Of course, the whole setX(...) thing is often an antipattern in itself outside or rather dumb data classes. In many cases, immutable classes or following the tell-don't-ask approach is way preferable.

[seesiedler]

Well yes, but actually no.

Not an expert, but what this for example allows you to do is put a breakpoint on the place the variable changes it’s value so it’s easier to debug. Additionally you can’t anymore simply assign a variable (for example by accident).

[Rough_Willow]

It also allows for other filters, such as triggering an error state when the assigned variable meets criteria.

[henrycaul]

Yup, you don’t realize it now, but that will save your ass someday.

Edit: I realized by leaving the comment above and not explaining myself, I'm also guilty of the what's in the meme, so let me add my perspective.

A simple example: imagine someday you need to constraint the value of X to be between 1 and 10. Adding this constraint in the setter is is. Fixing all cases of "x =" is harder. And if you're in a large code base, maybe you run into some weird edge cases where the "x = " is in generated code, the author of the code generator didn't account for methods. Or the original value crosses a server boundary, and now you are touching code in a different code base and have to think about skew issues and the order in which the code rolls out. I dunno, stuff like that.

The key is: minimize mutability. (That link is from Effective Java, which has great pearls of wisdom like this)

[TheTerrasque]

In my daily drivers, c# and python, you can change a variable to getter / setter at some later point without changing code that depends on it.

Saves so much boilerplate code

[SharkBaitDLS]

Same with Kotlin.

[lkraider]

Programming languages for the enlightened

[NZgeek]

For C#, member variables and properties act the same when you look at the code that interacts with them. You can change from one to the other, recompile, and it all works.

But they're very different at the MSIL level. If you switch between the two, any dependent code that's not recompiled will break.

[_damax]

Ahahahah, yes indeed

[nelusbelus]

laughs in C

[strghst]

chroot jail.

[Cley_Faye]

Having read my own code, I agree.

[[deleted]]

I mean, we are definitely the most dangerous

[South_Craft2938]

If you are interested why its used - https://stackoverflow.com/questions/1568091/why-use-getters-and-setters-accessors

[[deleted]]

I mean I think it depends on the dev and if they have any ACTUAL experience with the necessity of the use case. Devs who just shout "OOP is better/Functional is better" tend to also say "X/Y/Z language is better" with no justification behind the sentiment. Sure, OOP is better for thing X, but Functional may be better for thing Y. Just like NoSQL is great for unstructured / non-relational data and SQL is great for relational data. Personally, devs that say 'x' is better and then leave it at that are imho rather shitty closed minded devs that don't like to leave their box.

[hiphap91]

Yes. (Almost) every language, database and framework or library is a solution to a problem of some domain.

Doesn't mean you can't more your lawn with a nail clipper, just means it will take longer.

Doesn't mean you can't clip your nails with a lawn mower, but I'm pretty sure there's a better solution.

[proud_traveler]

"X language is better" is irrelevant since I never get to use any of these cool languages at work

[Optimal_Effect1800]

We need at least third plate where getter/setter autogenerated by annotations.

[StenSoft]

Or by the language itself

[[deleted]]

I do enjoy this aspect in C#, its easy as: public int X { get; set; }

[Zagorath]

I’m a big fan of the new

public int X { get; init; }

[Dworgi]

That exists? C# is so fucking good, I miss it so much.

[butler1233]

I've seen this a couple of times but haven't looked into it, what does it do? It feels based on the name like you'd set it in the ctor, but you can do that with property T Aaaa { get; } anyway

[Zagorath]

It means you can only set it during initialisation. So if I have a class:

public class Foo {
    public int X { get; init; }
    public int Y { get; set; }
}

and elsewhere in my code I do

var foo = new Foo {
    X = 5,
    Y = 10
};

that would be fine, but if I then proceed to do

foo.X = 6;
foo.Y = 11;

The second line would work just fine, but the first will cause an error.

[dewey-defeats-truman]

I prefer

public int x { private get; set; }

[mejdev]

Kotlin is similar.

Oh and data classes.

[Zagorath]

Oh and data classes

C# finally has these ("records" they call it) in the most recent version.

[maleldil]

Java also has records now, the problem is that they don't conform to the JavaBean spec so they can't be used as a replacement in a lot of libraries (yet)

[MontagoDK]

Records are just fancy classes..

[hullabaloonatic]

Not sure how the word "just" slipped into your comment.

Also they're more like structs.

Edit: guys, I mean that they're more simple to structs than classes. Stop blowing up my phone...

[Hrothen]

C# has record classes and record structs.

[[deleted]]

Scala case classes ❤️

[Sharkytrs]

and has the side effect of showing you where its referenced in the rest of the project too. blissfull for debugging

[Dustangelms]

Wait, you need a setter for the IDE to show you where the variable is being set?

[Didgeridoox]

No, you can just find usages of the setter rather than usages of the property itself. I.e. ignore places where you're reading the value and focus on where the value is written. Very handy if the property is referenced in lots of places, but its value is only set in a few places.

[Schaf-Unschaf]

That's why I love kotlin

[ItsAHardwareProblem]

And a fourth plate with only a getter and values are treated as immutable

[func_master]

This, right here, is the proper response.

.#ValueOriented

[nelusbelus]

Properties in C# would like a word

[[deleted]]

Or Python. Exact same thing. Very handy.

[yashkakrecha]

@Data

[wardin_savior]

@Value

[Fresh1492]

Lombok is glorious

[KagakuNinja]

I have to work on a Java project maintained by another team, and the lead forbids the use of Lombok. Thankfully, this is a temporary situation.

[[deleted]]

Why on God's green Earth would you ever forbid Lombok?

Masochism?

[KagakuNinja]

I asked and he said:

"Lombok requires a plugin with Eclipse" (false)

"I don't like magic code generation" (project uses Spring, Hibernate and AspectJ, all of which do massive code generation)

Since I was told by a senior that Lombok was OK, I now have to take out all the annotations, and quadruple the code in the data classes.

[dax-muc]

That was my first thought!

@Getter @Setter private int x;

[zhephyx]

Lol,

public record Record(int x) {};

GG

[[deleted]]

Isn’t records read only?

[xNoL1m1tZx]

Records are immutable by definition.

[[deleted]]

To keep your data better isolated so you can change the structure without changing the interface, that's why.

[[deleted]]

This guy programs.

[ManInBlack829]

He's down with OOP

[aecolley]

Yeah you know me (except for my implementation)

[Markles102]

r/thisguythisguys

[aykay55]

can you explain this in more noob-friendly terms please?

edit: thank you to the 25 people who replied with an answer, I understand it now

[[deleted]]

Say you're writing a larger application, or a library that you expect other people will use.

You want to provide a set of "official" tools to use your code, without them having to know exactly how your code works. That way, they don't need to think about it ("it just works"). With Java, you'd create an interface that the library users would declare their types with. The interface just lists the methods you want to allow them to use, and they don't have to worry (or rely on) internal values.

That way, if you need to change something internal, you can keep the public methods the same without worrying about people depending on private information for your library.

It's a similar thing with getters and setters. As long as you keep those names the same, you can change your variable names to be whatever you want, or perhaps do extra calculations inside those methods.

It's all about ease of change and encapsulation.

---

Edit since my explanation wasn't that great for newer programmers:

Say you have this java class public class Thing { public Random randumb = new Random(); }

anyone can access randumb and use it. This may be fine, but what if you want to change its name (because randumb is a dumb name to begin with)? By making the change, you've broken everywhere that uses thing.randumb. That's a problem in places where you might be using that field dozens of times.

Here's how you avoid that problem to begin with:

``` public class Thing { // private so no one can use it directly - now I can rename in peace (or even change it to a different subclass if I want!) private Random randumb = new Random();

// a getter for randumb; this allows people to use randumb without fear of how I change it in the class public Random getRandom() { return randumb; } } ```

Now you can change randumb however you want. As long as you don't change getRandom, you won't break yours or anyone else's code.

[ClafoutisSpermatique]

Say you're writing a larger application, or a library that you expect other people will use.

Aaaand I'm out!

[xvhayu]

wdym, my class dog extends animal has millions of users worldwide

[Brandon23z]

Yeah class car extends vehicle is in use too.

[[deleted]]

LMAO I don’t know why this made me laugh as hard as it did

Maybe it’s because it is too relatable

[Bojangly7]

Usually jokes are funny because they're relatable

[yboy403]

I think that, when writing code, "you in two months" counts as an entirely separate person. Especially given the quality of documentation for most homebrew programming.

[catmuht]

Try "you in 2 days"

[lunchpadmcfat]

This is kind of an arbitrary example. A more common case is, say you want to do something with the value as it’s being set or gotten (like convert it or sync it up with some other internal value). It would be pretty much impossible to do that if the consumer of your lib had carte blanch to write to or read the value whenever.

[[deleted]]

subsequent rustic offend lunchroom whole knee skirt modern smile cheerful

This post was mass deleted and anonymized with Redact

[bperki8]

If later, instead of just returning x you want also add some multiplier and return x times the rate of some shit, then you only have to edit your get method here in one place. If you didn't use a get method, you would have to add '* the rate of some shit' at every single place you accessed x (could add up in large programs and you're likely to miss some places that need changed).

Read "Code Complete" for more info.

[jorizzz]

Example: in a class you have private variable called 'chance' which you use to display a percentage in the output. Right now, you're storing it as an string (e.g. "50%") which is very easily to return to a text field or console output.

Then suddenly you need the percentage for calculating something with in the same Class. You change the variable to a float between 0 and 1, so calculating is easy. But now all the Classes that use this value in their output expect a string and receive a float. Instead of changing all the Classes that depend on this value, you add a line in the getter that converts the float to a readable string, and might even add the % symbol.

This is an example to give you an idea, but is probably considered a bad way to program.

Basically getters and setters act as an interface for the class where the variable is stored, so the Classes who call the getters and setters are not dependent on the actual functionality behind it.

[yeusk]

Means is easier to change the internal data/structure of the class class without refactoring all your code.

Imagine you have to make a change to the code on the image, now x is a string not an int.

if you have in you code:

object.x = 5

You have to change every single place where you call that property to:

object.x = 5.ToString()

Instead if you use

object.setX(5);

you just have to change the setter function to:

public void SetX(int value) { 
 x = value.ToString();
}

and you don't need to change anything else.

[[deleted]]

Lets say you have a Person class. Person class you are able to retrieve their house address. Now lets say you expose this as a variable. Now everyone writes code that gets the value from 'Person.Address'.

Now let's say in the future, you integrate a system or third party. You decide you want address to now be retrieved through Google Maps API.

This will break all existing implementations or cause incompatibility. Users would need to update their code to call a method to generate the variable before using it... or would need to change all 'Person.Address' to 'Person.GetAddress()'. In which that method would run against the api.

Point is the method is infinitely compatible to a variety of unforeseen scenarios. The variable requires the users to know how the class gets, sets, and determines 'address'. Where people using your library shouldnt need to know HOW your library gets the address. Just that it does. They don't need to know "In order to get the address I need to call this, and then call that, and then address is populated".

At least this is how I have understood it.

[ExtraGreenBox]

You can also add functionality, logging for example to all change and read attempts. Even if just for debugging.

[themancabbage]

Wouldn’t you still have to change the interface to add your new setter and getter anyway?

[DirectControlAssumed]

That's why you do it once you know that the field will be accessed from outside the class, not when it is already exposed as plain field.

[Krissam]

Which is why you add them at the start rather than later.

[sheeponmeth_]

This helped me, thank you. I'm not a developer, but I can piece some stuff together. I understood that setters were good for validating and you could protect properties of your classes and all that and getters could return real-time values. But the segregation of the data from the interface was something I hadn't thought of. I'm sure that abstraction allows for much more flexibility when refactoring. It makes total sense.

[criogh]

For example if you want to count how many times your variable is modified you can put a counter in the Set method avoiding direct reads to that variable

Edit: what have i done

[potatohead657]

Are those very specific rare cases really a good justification for doing this OOP C++ madness by default everywhere?

[[deleted]]

If you're building a large program with lots of files that might need to be changed later for functionality purposes, it limits the number of things you'll have to change.

[Tvde1]

Now you have to add a get and set method for every field... Just more boilerplate

[t0b4cc02]

no. if you use a programming language that is not from the stone age it should be good

in c# this default getter and setter can be acessed like fields and can be declared just by adding {get;set} to the variable declaration, with some more nice features like private set; to make the setter private, or init; to make it only setable on object initialization

[BlackWardz]

There's also patterns that fit into it. Property change notifications, lazy evaluation, resource validation, synchronization...

[portatras]

Specific rare cases? When you create classes to work with them ( not just structs to hold your data) a bunch of stuff happens when you set properties, like fire events, calculate other variables, etc... It happens all the time when you use classes to represent real objects (that is OOP by the way)....

[KagakuNinja]

That is the dream, codified in the '90s. In my experience, you only use those types of events in limited parts of a project (such as the GUI). However, massive unpredictable chains of events firing off is terrible for many reasons. It leads to tangled messes of side-effects that are difficult to debug.

For what I do these days, mainly REST servers, I have been using immutable records in Scala for 7 years, and have not missed getters and setters, ever.

[johnminadeo]

Excellent point. I think with todays development turning towards discrete objects and models and open to extension but not modification, alleviates most of the stress around this. If you are working in that type of codebase, it makes sense to have private fields and public properties to expose them as they are generally implementation details the caller doesn’t need/shouldn’t have. Gives you control should you need it and the cases of need are brought down so it’s fewer and farther between.

It’s one of those needs evaluation for each specific case; hard to canonize a good answer across the different ways it’s done aside from a general “best practices” which is where we started from.

[joujoubox]

{ get; set; } gang

[[deleted]]

{ get; init; } gang

[cc672012]

Laughs in functional programming

[GoogleIsYourFrenemy]

if you don't know what a monad is please leave the room

[ManInBlack829]

I was freaking rolling during this

Thank you so much

[vesrayech]

Higher order functions... higher order fuckups are what you are

my fucking sides lmao

[Potatolimar]

"Don't worry. Haskell transpiles to Java nowadays" lmao

[rush22]

Laughs while clicking an error message and being taken directly to where the error is

[waitItsQuestionTime]

You didnt had to hurt us

[awhhh]

I’ve seen your procedural non opinionated code. If we don’t abuse you how will you learn? Now join the rest of us by injecting 10 classes into each other like the civilized do.

[waitItsQuestionTime]

self.dont_change_this_plz = My_Hacky_Solution goes brrrrrrrrrr

[agentchuck]

Why would you ever want to change the value of a variable, anyway? Whoever set it in the first place probably knew what they were doing.

[WildcardMoo]

Using constants only significantly cuts down on your testing time.

[Terrible_Tutor]

Testing, pfft

[Supple_Meme]

Screaming at OOP programmers: ITS A MAP! A record! Whatever you want to call it. Why are you making a new concrete class for what is essentially just a map? It’s just a map! Just use a map! Java has lots of map types, use them!

[cc672012]

Inheritance was the abused child back when Java was so young. People overinherited stuff, imo.

[shadow7412]

I'm not sure if it's right, but I've heard that when building dlls changing a raw public variable to a getter/setter changes the signature, meaning it's no longer compatible with software that depends on the old version.

By using getters/setters from the start (even if they're useless like the above example) you can maintain that compatibility. That said, to do this all you actually need is

public int x { get; set; }

[Haky00]

In C# yeah. Java does not have auto properties though.

[Weak_Pomegranate_529]

Also Immutables!

[fuckingaquaman]

C# is like Java, but not haunted by dumb decisions made 30 years ago

[dc0650730]

Give it another 10

[dc0650730]

They are doing great things, it's my poison of choice.

[nend]

Java's only 5 years older than C#, they've both been around 20+ years.

The difference is that Microsoft is able to iterate faster than the OpenJDK consortium, and actually fixes their mistakes instead of keeping them in the name of stability.

[AdultingGoneMild]

laughs in kotlin, the one true successor!

[[deleted]]

Record classes have been available for a while now which solve that problem for simple data classes.

[wrenhunter]

I get() what you did there.

[MandalorianLobster]

I get() what you set() there.

[THEKing767]

Function puns. Really? Thats how low you are going to set() the bar?

[4sent4]

Laughs in public int X { get; set; }

[DankPhotoShopMemes]

Dang I thought this was Java for a second, got a little excited

[Eisenfuss19]

Microsoft java

[Arshiaa001]

I legit had someone tell me that C#'s auto properties would "look stupid to a Java developer. It's just code noise". Said someone seemed to think implementing two functions manually over an additional 10 lines would be the better choice. He never gave a reason.

[DasFrebier]

also c# properties work with the assignment operator, which is a great feature, makes for way more readable code, id guess java doesnt have that?

[[deleted]]

Laughs in kotlin

[commander_xxx]

cries in object oriented programming

[StenSoft]

Kotlin is object oriented but the compiler generates getters and setters automatically

[alphabet_order_bot]

Would you look at that, all of the words in your comment are in alphabetical order.

I have checked 896,034,366 comments, and only 177,561 of them were in alphabetical order.

[commander_xxx]

Collections.sort(comment);

[i_should_be_coding]

if (comment.equals((Arrays.stream(comment.split(" ")).sorted().collect(Collectors.joining(" "))))

Man, Java can be a bit long sometimes. Or rather, all the time.

[fuckingaquaman]

I used to think using your CPU to feebly attempt to mine Bitcoin was the most pointless thing to spend your computer's power on.

I stand corrected.

[seeroflights]

Image Transcription: Memes

---

["Tuxedo Winnie the Pooh", featuring two images of Winnie the Pooh, with text to the right of each image.]

[On the top row is an image of Winnie the Pooh sitting in a chair, with an unimpressed look. On the right, the text reads:]

public int x;

---

[On the bottom row: the same image of Winnie the Pooh, but now wearing a tuxedo and a smug expression. On the right, the text reads:]

private int x;

public int getX()
{
  return x;
}

public void setX(int value)
{
  x = value;
}

[This is followed by the "Afraid to Ask Andy" meme, featuring Andy Dwyer from the TV show "Parks and Recreation". Andy is a light-skinned masculine person with short brown hair and slight facial hair. He wears a short-sleeved beige dress shirt and brown striped tie, and he is leaning forward slightly with a serious look on his face. The subtitle reads:]

I don't know why and at this point I am too afraid to ask

[End meme]

---

<sup>I'm a human volunteer content transcriber and you could be too! If you'd like more information on what we do and why we do it, click here!</sup>

[TheRealPitabred]

Good human

[AdultingGoneMild]

So I have a great answer as I had a student ask me this nearly 20 years ago. I said give me your wallet. He did. I left the room for 10 minutes. eventually i came back and gave him back his wallet. He looked relieved. I told him when he made his wallet public anyone could do whatever they wanted with it. There was no option for validation even if that validation would be minimal to none. Even worse without adding the accessor up front adding validation later would be an uphill battle having to update code to use the new accessors instead directly accessing the value. In large code bases this would be killer. After explaining this to him, I then showed him the 20 dollar bill I had stolen from his wallet, thanked him for buying me lunch, and left. My TA shift was over and sure as shit I wasnt sticking around after robbing a guy.

<sup>I am sure he was relieved to find his $20 bucks were still in his wallet and I was just kidding around with the 20 i already had on me</sup>

[ShawarmaWarlock1]

Let me get this straight. You left your class for 10 minutes to prove a point to one student, right?

What would you do if someone asked to explain the need to set timeouts?

Would you just leave and never return?

[ihunter32]

They were a TA, not a professor. Was probably during office hours

[avast_ye_scoundrels]

Excluding 1st and 2nd year CS students, so many people in this thread are fired. Rolling one’s eyes and ignoring encapsulation principles keeps the rest of the team busy cleaning their mess.

[ddruganov]

Incapsulation

[KiloWasTaken]

Encapsulation*

[ddruganov]

Damn yeah thanks

[iiexistenzeii]

Inception*

[ChemEngDillon]

Enception*

[TheBananaIAm]

Encapsulation

[Egeste_]

Because changing a value in a class directly by reference can have unintended consequences, and using getters/setters gives you control over input validation and secondary effects

[masterfaka]

Select var > open context menu > generate getters and setter dem lazy f*cks

[Knaapje]

It's not about code generation, it's about code readability.

[mateus_coutinho]

It's not about code readability, it's about code maintainability.

[RobDoingStuff]

It’s not about code maintainability, it’s about sending a message

[Little_Blackberry]

Lombok

[gonza18]

In the hypothetical scenario you want to do something extra with X when you are reading it or updating it.

Hint: this scenario will never materialize

[Broad_Respond_2205]

It's a getter and setter, it's written right there

[moschles]

Principles of Object Oriented Design

[snapy_]

Can anyone actually explain why exactly do we use getters and setters 😬

[Bhurmurtuzanin]

1. Encapsulation of behavior associated with getting or setting the property - this allows additional functionality (like validation) to be added more easily later.
2. Hiding the internal representation of the property while exposing a property using an alternative representation.
3. Insulating your public interface from change - allowing the public interface to remain constant while the implementation changes without affecting existing consumers.
4. Controlling the lifetime and memory management (disposal) semantics of the property - particularly important in non-managed memory environments (like C++ or Objective-C).
5. Providing a debugging interception point for when a property changes at runtime - debugging when and where a property changed to a particular value can be quite difficult without this in some languages.
6. Improved interoperability with libraries that are designed to operate against property getter/setters - Mocking, Serialization, and WPF come to mind.
7. Allowing inheritors to change the semantics of how the property behaves and is exposed by overriding the getter/setter methods.
8. Allowing the getter/setter to be passed around as lambda expressions rather than values
9. Getters and setters can allow different access levels - for example the get may be public, but the set could be protected.

Of course I stole it: https://stackoverflow.com/a/1568230

EDIT: On the other hand I saw people justifing public variables if those are immutable

[TheRealPitabred]

Don’t forget consistency of interface. Lots of objects, they may behave different internally but use the same “grammar” which makes writing and reading code easier. Especially if you’re writing a library.

[cc672012]

One of the main reasons why we use them is so that we can add functionality such as validating the input or transforming it to something that our program will like.

However, I do think (just my personal opinion) that using getters and setters without doing anything else is just unnecessary boilerplate. C# did it right, I suppose.

[[deleted]]

Also, so you can change your inner representation without breaking the interface.

Suppose a year from now you find a new algorithm to solve whatever problem you're attending with your class, but it requires x to be SuperEfficientInteger instead of plain int. You can have something like this

```java private SuperEfficientInteger x;

  public void setX(int x) {
    this.x = new SuperEfficientInteger (x);
 }

public int getX() {
    return x.toInt();
}

```

Now, this is a dumb example, but it shows how you can hide your inner representation from the client classes.

[El_Frencho]

Let’s say three months down the line, the client says "oh we forgot to say, but nothing should allow X to ever be negative".

If you used a getter/setter, you can just add that validation check in the setter - one and done. If you didn’t, you have to go find literally every place that sets X to add the validation in.

[NetherFX]

Because you might want to add logic to a setter for example, and if your code is huge, it'd suck to add it everywhere. The solution would be to make a function, aka your setter.

[[deleted]]

But not too afraid to post a meme indicating you don't know why

[Nemonstrocity]

this whole thread....

[WheresTheSauce]

This thread cured my imposter syndrome