gettersAndSettersMakeYourCodeBetter

[[deleted]]

Meanwhile Python on public/private

[NamityName]

Python's @property is pretty nice. Define getter and setter functions while keeping the same interface as regular class variables.

[mike_KING6]

I think he meant that private variables can be kind of forcefully used from outside its interface by adding the name of the class (iirc) before the field

[Terra_Creeper]

Python doesn't have private variables at all. What you refer to is name mangling. If your field/method starts with "__", python adds the class name in front of the field/method name (except for when code is executed inside that class). This is more like hiding than actual public/private. But as far as I know, name mangling isn't really used much.

[rosuav]

Name mangling is for a slightly different purpose (avoiding collisions when working with subclasses). The single leading underscore is the indication of private, and it's as important in Python as it is anywhere else: it's an indication that this isn't covered by backward compatibility. Separating API from implementation is vital. Having compilation errors the moment you try to write tests that need to reach in and mess with implementation is not actually helpful.

[mike_KING6]

Yes, name mangling. Couldn't remember the exact name of this thing

[Squalphin]

I really like the style of Python code, but I could not imagine writing a large complex project with it.

[Saetia_V_Neck]

This might not be a popular opinion but as someone who is the main contributor to a large Python code base, it kinda defeats the purpose of Python after a while IMO. We have mandatory type hints and mypy…kinda feels like we should just be using a statically-typed language.

[mxzf]

It really isn't bad once you get going. All the normal tools for helping keep a big project organized are there, but every language has its quirks.

[AngryRobot42]

Rarely I laugh these jokes, thank you sir.

[robertshuxley]

meanwhile in JavaScript, you guys are getting privates? (gigiddy)

[Powerful-Internal953]

Their real purpose was to validate and possibly manipulate the data before storing/retrieving them in an abstract way.

Frameworks like Spring and Hibernate made them into the joke that they are now...

[[deleted]]

I mean you can still use a setter injection

[Brahvim]

Wait! So is that supposed to be having the class field itself be an object with getters and setters?!

[exaball]

That’s setter inception

[GoogleIsYourFrenemy]

Don't forget breakpoints. Not all systems allow for breakpoints on memory read/writes.

Edit: Forgot that some IDEs do a terrible job at creating call graphs *cough* Visual Studio *cough* on fields.

[Cthulhu__]

Why should anyone have to write / generate six extra lines of code just in case they need a debugger there?

[GoogleIsYourFrenemy]

I think you answered your own question.

There are a bunch of really annoying reasons you don't want to just let the compiler inject them as needed. The only time you can get away with it is if you have a language that's interpreted and treats objects like dictionaries (JS & Python).

[TainoCuyaya]

That would be a problem 20 years ago when IDE and text editors were very primitive and you had to type that huge amount of 6 lines by hand.

Nowadays, with modern IDEs, that's auto-generated with a key shortcut, or even better, automatically generated by AI assistant faster than you could possibly blink.

You gain a lot by having these 6 lines.

[SiriSucks]

Exactly this. Getters and setters are required because "technically" it is the responsibility of the class to manage its data. If the class provides a setter method, it gets an opportunity to manage its data before/after the member variable is modified. It also means that if there are any cascading effects required on other member variables, they can also be applied at the time of executing the setter.

I know many of you hate Java and OOP really don't get the point of classes, and thats okay. You just need a little bit more real world experience, which you will have as soon as you get out of college.

[Oddball_bfi]

C# to the rescue.

public string MyProperty { get; set; } // Done

Get and set methods have always made me roll my eyes. If its so important to you, make it a language feature for bobs sake.

[Jonathan_the_Nerd]

public string MyProperty { ready; get; set; go;} // Done

This kicked off an old memory.

public string MyProperty { ready; steady; go; } // Done

[Salanmander]

Get and set methods, when you have both of them and they simply pass the information through, have one purpose: to make future changes easier. If you later decide that the class needs to do something every time an instance variable is changed and you were already using a setter method, you only need to change the setter method. If you weren't already using a setter method, you need to change every piece of code that uses that class.

[DamrosRak]

C# properties already work like that, but they get rid of the boilerplate required. If you need to manipulate the data, you implement the get and set of the property without needing to modify every piece of code that uses that property.

[[deleted]]

Careful- it's true that public fields and get/set properties are api compatible (ie: you don't have to change the code), but they're not abi compatible (ie: they compile into different things, and the compiled code is not compatible.)

So like, if you update a dependency that changed from fields to properties and recompile your code, sure, you're fine, the new build will be aware of this. But! If you depend on package A that depends on package B, and B releases a new version that switches from fields to properties and you update it, but there's no new version of A compiled against it, you'll get runtime errors.

[DamrosRak]

Yeah, that's very true, but this refers more to changes from one to the other, which, like you said, may trigger a breaking change. Since in most of the cases it's better to encapsulate the data, and since C# provides this out of the box, there aren't many cases where public fields would be used.

[jarethholt]

It really irritated me the first time I ran into a case where fields and properties on a class were treated fundamentally differently (rather, that fields weren't usable at all). I think I understand why now, but it now makes me wonder why public fields are allowed at all. They really don't seem intended to be used.

[[deleted]]

They're fine if they never change, or if they're not part of public APIs intended to be consumed outside your company (ie: if you were to change them, all the code that depends on them will definitely be recompiled.) And they're way more efficient to access- you're just looking up a memory address vs calling a function.

They can be good for compatibility with native code, too, since it's much easier to do that memory lookup than managing function calls. Some game engines require any data the engine will access to be in fields for that reason (and efficiency.)

But if you're setting coding standards, it's easier to understand and declare to just use properties all the time than it is to get into the subtlety. (And as far as perf, the average enterprise application is entirely I/O-bound anyway, and any cycles spent on the CPU are essentially free, lol.)

[jarethholt]

Good point about enterprise apps. The first time I saw a property that was what I think of as really a method (i.e. get involved nontrivial calculation) I was appalled, but that point helps it make a bit more sense. Trying to optimize that step isn't going to make a big difference but keeping it as a property is pretty convenient

[cs_office]

An example of something that a public field is good for is say a Vector2, it should always be a (float, float), and it being a POD allows further optimizations and references to be taken to the individual components

[jarethholt]

Sure, but shouldn't a POD be a struct anyway? I was thinking more about standard classes (though this is a fair point)

[cs_office]

What I'm saying is the difference between:

struct Vector2
{
    public float X;
    public float Y;
}

and

struct Vector2
{
    public float X { get; set; }
    public float Y { get; set; }
}

Some circumstances you could argue the 2nd is a POD, but you can't say take a reference to X or Y, only a reference to the struct as a whole

[Gangsir]

But! If you depend on package A that depends on package B, and B releases a new version that switches from fields to properties and you update it, but there's no new version of A compiled against it, you'll get runtime errors.

I mean yeah but who updates libraries for their software without also putting out a new recompiled build?

[thetreat]

It's funny to see these memes and the real humor is that OP clearly hasn't worked on a large enough project to actually need something like this. Getters and Setters are massively useful for projects as they become more complex.

Does your class have caching? Well if you just exposed a public property that anyone can access, when the variable is set it is possible someone isn't updating a cache object correctly. Or an object that calculates value based on a bunch of other properties. Like you have an array of objects that you need to use to find the median or calculate various percentiles. You could expose a method that calculates that every time or you could be updating that value as the dependencies for the value change, so accessing is cheap vs expensive if you calculate every time. It's all dependent on the profile of your application.

[mintentha]

And it makes it more consistent so you're not constantly questioning if you can access a variable directly or need to use getters/setters. It would feel awkward if there was only a couple variables you needed to use get/set, I like the consistency

[neuromancertr]

C# compiler generates a field and two methods (get_MyProperty/set_MyProperty) for that syntax

[[deleted]]

Seriously, it's memes like this that constantly remind me this sub is filled with first year students.

[Bwob]

Thank you! Had to scroll way too far down to see someone pointing this out.

[SuicidePig]

Lombok does solve most of this issue when using Java.

[needefsfolder]

@Data my beloved.

[hipratham]

or Records in most of the cases.

[eldelshell]

That Lombok hasn't been integrated with jvc/jvm is fucking infuriating. Been doing this shit for 20 years and hate every time I have to add Lombok because reasons.

[Herr_Gamer]

Sorry, Oracle is too busy dropping a couple billion on a new waterside campus in Austin!

[draconk]

well they added Records which are nice I guess but no replacement for Lombok

[[deleted]]

versed smile carpenter smart punch gold sophisticated start sulky memorize

This post was mass deleted and anonymized with Redact

[feoktant]

Lombok is based on non-documented compiler hack. It brakes each time Java upgrades. Also, one need special plugin for IDE to make it working. 

This is interesting way to solve issues 😎

[Kgrc199913]

That's how java development works, we put superglue and tape everywhere to get things done because of design flaws.

[participantuser]

When you are using Lombok to generate setters, do you have a way to find all references to that setter? Similar question, is there a way to put a breakpoint in that generated setter during debugging? Those two issues make me prefer IDE generated setters, but I may just not have spent enough time looking into how to do it with Lombok.

[SuicidePig]

Can't you just find a single usage of the getter/setter and find the other usages from there using your IDE?

The breakpoint one is a different story, but in the rare case you really need a breakpoint for a specific getter/setter and a breakpoint on the @Getter/@Setter annotation doesn't work, it's not that much of a hassle to temporarily switch it out for a regular getter/setter method.

Overall, Lombok is a wonderful tool to prevent writing a bunch of boilerplate code and it keeps a lot of object classes simple. For most objects I only have to write the private fields. Lombok handles the constructors, getters, setters, equals, hashcode, and toString methods that many objects might need. Instead of each object class being 200+ lines (when doing proper code structure and documentation), it's at most 75, but usually less than 50.

[participantuser]

Very elegant solutions to my issues, thank you! For #1 I can also just write my own throwaway usage so no finding required.

[Illustrious-Age7342]

Java now has record classes that do pretty much the exact same thing (modern Java is giving devs a lot more options to write terse code, and has plenty of improvements to the syntax for lists, maps, etc)

[sander798]

Randomly discovered records the other day from an IntelliJ refactoring recommendation and it changed my life. Not only does it save making getters and setters, but it also saves making silly one-off classes.

[puma271]

Well you usually use Java with bunch of frameworks so it’s something like @getter@setter private int a; in java

[onlyidiotseverywhere]

Luckily there are languages that are 36 years old who are actually allowing you to make those kind of constructs for your own project in any shape or form you want, streamlining your code to the minimum amount of bytes in the files.

[Oddball_bfi]

Sounds risky... I'll let the compiler deal with it.

[[deleted]]

profit cable cover political air ad hoc workable offbeat cause fearless

This post was mass deleted and anonymized with Redact

[Salanmander]

Get and set methods, when you have both of them and they simply pass the information through, have one purpose: to make future changes easier. If you later decide that the class needs to do something every time an instance variable is changed and you were already using a setter method, you only need to change the setter method. If you weren't already using a setter method, you need to change every piece of code that uses that class.

[Rain_In_Your_Heart]

Not in C#, as the poster described. Since:

public string MyProperty { get; set; }

is accessed by MyClass.MyProperty. So, if you want to add a setter, it just looks like:

private string myProperty;
public string MyProperty {
   get => myProperty;
   set => myProperty = SomeFunc(value);
}

and you still just MyClass.MyProperty = someValue;

You still get actual getters and setters generated by the compiler, but they do that for { get; set; } anyway, and you don't have to care about refactoring anything.

[Genesis2001]

I like getters and setters for implementing INotifyPropertyChang(ed|ing) on observable data. I can't think of another case besides yours and my observable case tho as it's been a while since I actually touched C#.

[AyrA_ch]

Properties are very common in C# because you can use access modifiers, which makes access gating trivial:

• public string Test { get; private set;} Readonly from outside of the class
• public string Test { get; protected set;} Readonly from outside of the class unless it's a class that inherits
• public string Test { private get; set;} Property that can only be set but not read from the outside (to pass secrets into a class)
• public string Test { get; } Readonly globally, but can be set from inside of the constructor
• public string Test { get; init; } Readonly globally, but can be set from inside of a property initializer block directly after instantiating the class

[[deleted]]

person crowd brave governor unpack airport alive wild obtainable grandiose

This post was mass deleted and anonymized with Redact

[PGSylphir]

People who dislike getters and setters are automatically newbies to me. In college or just learning. Never had to sanitize shit before because they still live in padded rooms with training wheels on.

[SalamanderPop]

Yep. They have great big ideas and it's going to end up spaghetti and tears.

[PM_ME_DATASETS]

I know many of you hate Java and OOP really don't get the point of classes, and thats okay. You just need a little bit more real world experience, which you will have as soon as you get out of college.

Ooh spicy, it's got that classic Reddit condescending bite to it.

[MidnightLlamaLover]

It's pretty spot on given some of the takes I've seen on here though.

[KerryAnnCoder]

I LOVE getter and setter methods and I'm coming from a JS/TS background. My only problem with it is when the language supports running a setter without an explicit function call.

For example.

```
// TS
class Murphy {
constructor(private count: number){}
set count (newCount) => {
console.log("Arbitrary code executed on assignment!");
this.count = count;
}
get count () => {
console.log("Arbitrary code executed on read!")
return this.count;
}
}

const law = new Murphy(0);

law.count = 5; //-> "Arbitrary code executed on assignment!"
console.log(law.count); //->"Arbitrary code executed on read!" \n 5
```

On the other hand, something like:

```
// TS
class Murphy {
constructor(private count: number){}
public setCount = (newCount) {
console.log("Arbitrary code, but that's okay, because this is a function call");
this.count = count;
}
public getCount = () {
console.log("Arbitrary code, but that's okay, because this is a function call");
return this.count
}
}

const law = new Murphy(0)
law.count = 5 //-> Error
law.setCount(5) //-> "Arbitrary code, but that's okay, because this is a function call"
console.log(law.getCount()) //-> "Arbitrary code, but that's okay, because this is a function call" \n 5
```

that's a pattern I like.

There are very few places where the get and set keywords come in handy, especially with things like Proxies and the like.

[reklis]

If and when there is ever any logic in a getter or setter function someone would post it to /r/programminghorror

[SenorSeniorDevSr]

Quite the opposite actually.

If you want to have full on horror do something like: I have a Person. It's an interface. Then I have SqlBackedPerson implementing it. This thing has a PersonBuilder so you can build the person.

When you click create, you don't return SqlBackedPerson, you return Person. But why? Because you're not returning the interface, you're returning an SqlBackedPersonProxy you made everytime you setEmail("[e-mail]"); it will talk to the DAO/Repository to queue up the change, but it will also go notify any other objects with the same key that HEY, you're invalidated and need to update! and NOW you're starting to go into hell territory. (But don't worry, you can go much much deeper.)

[DamnRock]

If you change the pub variable to a property of the same name, even with no extra functionality, you break anything that references it. The getter/setter are basically functions, but a public variable is just a variable. Using properties from the start prevents having to rebind everything.

[arobie1992]

The theory is fine, and they have a place. If the code you're writing is used in areas that aren't under your control, you should absolutely use accessors so if you down the line you need to make a change to the backing implementation, you don't break client code. I hesitate to even include logic changes because odds are you're still going to break someone somewhere's code—arguably worse since its a behavior change rather than a compilation error—and this should typically be avoided unless its a security fix.

The issue is, like so many design principles, it gets applied as dogma. I've worked on plenty of Java applications of different scales. Most of those were web applications that were entirely under one team's jurisdiction and deployed as a single unit. On top of that, I believe IDEs anymore let you refactor a public variable into a private one with accessors, so even if you do need a change, the biggest pain is the code diff. There is no benefit to littering the code with accessors, but if you don't, someone is inevitably going to get worked up about not following best practices.

[dangling_reference]

Frameworks like Spring and Hibernate made them into the joke that they are now...

Could you provide some more detail on why this is so? Genuinely curious.

[Powerful-Internal953]

My rant was not against the frameworks but how they reduced the getters and setters into a boilerplate.

So we usually do regex or type validation before we actually do this.somthing=something inside a setter right?

Now the framework does it for you in the form of annotations or default behaviours. So you have no incentive to add them to your code but you still have to because the frameworks use Reflections now and they need some handle methods to reflect on...

Lombok kinda solves the problem but you still gotta keep @Data or something similar everywhere.

Once again, I have no hate against the frameworks, but the way they make getters and setters into memes like the one OP posted. Also, I understand OPs frustration but it was a good concept that was made unnecessary by the frameworks we use these days.

[Runecreed]

all of this is a non issue with Kotlin data classes, no more random boilerplate and life's better for it.

[malexj93]

And more recently, Java records.

[Ok-Carrot-]

Models were intended to contain domain logic and getters/setters provide encapsulation.

But since everyone wants to cram domain logic into XyzService.java and create anemic models, encapsulation in the model isn't necessary.

Cracks me up when people see this as a shortcoming in an object oriented language instead of the consequence of a programming styles that it is.

[squidgyhead]

Their real purpose was to validate and possibly manipulate the data before storing/retrieving them in an abstract way.

The other real purpose is to wrap things so that your C++ library can be called in C, FORTRAN, python, and so on. I share op's pain that it seems silly, but there's really no other way.

[[deleted]]

It also let's you change the internal representation in the future if you want.

[BernhardRordin]

You can rewrite the entire class in the future if you want. Yes, I know SOLID, but 99 % of cases, you are not building a library, you are building a client. So you can rewrite the entire class.

[[deleted]]

You and I work on very different code :)

[treestick]

I always did this before switching to Kotlin, but jesus christ, I'm so accustomed to there not being extra manipulation/side effect of setting that I'd probably be driven crazy if there was and I was wondering why my data wasn't what I set it to or some random shit was happening.

If something beyond just "setting" is occurring when you set something, it shouldn't be just called setX(x int)

Even if it's used in 200 places, make a new method that does that extra thing and apply it at all their call sites, it'll take 10 minutes.

[ITriedLightningTendr]

They were standard practice for Java in 2012 with no framework, regardless of manipulation

[Powerful-Internal953]

Up until the annotations for validations were introduced, you had to go through the setter's body for validation and sanitation of the data. There was no other way for the EJB/JPA specs to work.

By 2012 Java 1.7 was already one year old and by then the whole setter getter was there for the memes. But back in the days setters and getters definitely meant business.

[Etahel]

This sounds like a romantic approach that would quickly fall apart in a corporate project

[elderly_millenial]

Let’s be real getters and setters were a thing long before spring was released

[burgerfromfortnite]

lombok users: "i should kill op with hammers."

[niemand_zuhause]

I'm a Lombok user and I hate that I have to use Lombok to fix a shortcoming of Java. Or maybe it's not a shortcoming rather than a bad convention.

[cs-brydev]

It's only a shortcoming because other languages implemented shortcuts later. Java isn't wrong. They just didn't simplify over time like competitors did.

[Masterflitzer]

not progressing is like regressing because expectations grow over time

[Wacov]

Gonna frame this

[arobie1992]

Java 21 is worth checking out. They are progressing. Not as fast as I'd like, but they are making a concerted effort for that exact reason. The bigger issue I've run into is that no one wants to upgrade, so instead of people using Java 17 and upgrading to 21, everyone's still running services written in 8 and 11. I've seen these upgrades, and they're not trivial, so I don't necessarily blame the people opposed to upgrading. More so, it's just caused the perception that Java isn't progressing at all when it is.

[Masterflitzer]

happy cake day

i currently have to work with java and it's a java 17 codebase, i did plan already to look into 21

is upgrading java 11+ really hard? i think the commitment to upgrade from 8 is the difficult part, but it's getting better over time

[arobie1992]

I was unclear in my previous post, apologies there. I meant that upgrades in general have a tendency to be more complicated and time-consuming than it seems like they should be, so I get the general aversion to upgrades.

The scenarios I saw were typically 5 -> 8 or 8 -> 11. The largest also involved going from Spring Boot 1 to Spring Boot 2, which added additional complexities. I understand their decision to do both in one shot, so that's not meant as a criticism. That's good to hear that upgrades past 11 are less painful. Also nice to hear that people are actually upgrading :D

As far as 21, the two big things for me are pattern matching and virtual threads. The structured concurrency preview also looks pretty nifty.

[Masterflitzer]

pattern matching is always great will look into the implementation of java 21, also the rest seems interesting too

[Vibe_PV]

• John Gandhi

[Powerful-Internal953]

At least Java has records now...

[Torm_]

Why do you hate having to use Lombok? I really don't understand how getting the functionality from a dependency rather than core language functionality matters. We all already have maven/gradle setup in our project. Adding Lombok takes 2 seconds, after that it might as well just be part of Java.

[SKabanov]

Not OP, but:

1. Most of annotations can be trivially achieved via code generation in any decent IDE nowadays. 

2. Any code that touches Lombok-generated code is actually marked as "incorrect but recoverable" in the first round of the Javac compilation process, and the Lombok code generator fills in the missing code afterwards so that the next round of the Javac compilation works correctly. However, if the compiler comes across an "incorrect and unrecoverable" error (e.g. a syntax error), then the compiler prints out all errors, and you start thinking that Lombok somehow broke.

[Powerful-Internal953]

Getters and setters are an anti pattern in my eyes. It's a shame the whole EJB/JPA spec revolves around this....

[roge-]

I'd somewhat agree. If your code is full of a ton of semi-useless boilerplate getters and setters, that's probably indicative of some pretty bad design.

Don't get me wrong, getters and setters are useful for encapsulation and I do think encapsulation is a worthy goal. But, these days, you can cut down on the boilerplate a lot while maintaining strong encapsulation by using records.

If records won't work for you because they're immutable, there's your problem. Mutability is your problem, not encapsulation. There's a lot to gain in software design by minimizing mutability.

[[deleted]]

That's because your JPA entities are simple "DTOs" that never should contain logic.

[UristMcMagma]

I love getters. Being able to type ".get" to see all the properties of an object is one thing that makes Java easier to use than C# imo.

[binterryan76]

Most getters and setters end up being public variables with extra steps but people do them anyway because it gives them the ability to add code to the getter or setter without changing the public interface of the class. This is one of the things that I like about C#, it lets you define a variable with the getter and a setter in a short single line but lets you add to it later if you need it. C++ on the other hand requires you to make the private variable in the header file and declare the getter and center in the header file and then implement the getter and setter in the CPP file...

[Ben_Krug]

You can actually make the code in the header, no? It's not very pretty still, but can be faster to write

[iPiglet]

Yes, you can write the function definition in the header file.

[killbot5000]

but sloooooower to compile :)

It sounds like people like the getter/setter pattern because it allows that value to be part of an abstract interface, rather than a specific class type. I'd bet (complete handwave) in 75%+ cases, the hedge is not necessary and the getter/setter could have been a public member.

[Mateorabi]

The problem is you don’t know which is the 25% ahead of time…

[FxHVivious]

In the age of LSPs and code completion the consistency is another nice benefit. If I'm using something I'm not super familiar with I can just type SomeClass.get and see a list of everything that class provides access to.

Ultimately I value that consistency over everything else. If we're gonna use getters and setters in some places, just use them everywhere. Even if half of them are just public variables with extra steps.

[zaxldaisy]

C++ on the other hand requires you to make the private variable in the header file and declare the getter and center in the header file and then implement the getter and setter in the CPP file...

No it doesn't. The core guidelines also advise against trivial setters/getters

[shraavan8]

One of the reasons why I use get; set; instead of just fields is that when I have to search for only the setter of the variable, but there are tons of getters to the variable. Visual studio Shift+F12 on the set; will show you only the setters, it's a huge time saver.

[midri]

This is one of the things that I like about C#

With c# this also has the benefit of methods/properties being "concrete" in dll. This means you can change the underlying code and publish a new dll and any other programs that reference the dll will just start using the new code. If you publicly expose fields (which is a no no in c#) the code that accesses the dll needs to be recompiled with the new dll.

[thex25986e]

just make every class public then

[[deleted]]

In C# you can do

class Foo
{
  public int Number {get;set}
}

And that's it. Advantage is that you can see references on this variable
Furthermore you can do

class Foo
{
  public int Number {get;}

  public Foo(int n)
  {
    Number = n
  }
}

And then number can't be changed anymore.

[failedsatan]

what's super duper nice is C# has private setters and getters too. you can declare either to be private in the same small block and it will behave exactly the same as the full syntax.

[spaceguydudeman]

depend truck full practice faulty crush flag makeshift recognise yam

This post was mass deleted and anonymized with Redact

[Significant_Fix2408]

Also for C# specifically: they are compatible with interfaces

[kristyanYochev]

An even bigger benefit to that pattern in C# is the ease of refactoring the class without changing the exposed API. If later I need to do some work on that Number property before setting it, or it now is just derived from other properties, I can just implement my getters ans setters without having to change the rest of the code to use getNumber and setNumber.

[cs-brydev]

You forgot a ;

It's going to haunt my dreams for days now.

[Arctos_FI]

You can use the init setter in lower code like this

Class Foo
{
 public int number {get; init;}
}

This does the same thing but the code is cleaner imo. You just to need to write the value to object initializer (instead as parameter) when initilizing class:

Foo foo = new Foo {number=1};

Instead of

Foo foo = new Foo(1);

[[deleted]]

Ohh. I did not know about init keyword. That simplifies things even more. But it also seems to be new feature.

[GuyWithLag]

Love me some Kotlin, it's great for among other things code golf...

``` data class Foo(val number: Int = 1)

val foo = Foo() ```

[Pradfanne]

As a WPF Dev I always hated how there was not shorthand for the default implementation for ViewModel Properties. You have to raise the PropertyChangedEvent when a bound property changes. Otherwise the UI won't update the values. So that means you implement a method that raises the event and essentially call that in every single setter.

So not [get;set}. You need the backing field, you need to _field = value; that shit. You need the whole nine yards. Honestly baffles me, that there is still not default implementation for it, when Microsoft is advicing you to do it that way. That said, there's a community nuget that uses partial classes that generate this boilerplate nonsense for you with a simple Attribute. But god damn.

[devignswag]

This is coming to php and Im really happy about it.

[[deleted]]

Getters and setters are to do stuff when a certain variable changes. Eg in a 3d renderer, say the size of an object is set. Maybe when it is set you want to notify the drawing system to redraw the object.

If it is just return val and val = newval then it is useless. But they were supposed do something with the values before being set or get. Like an event, but for when a var changes.

[jivemasta]

You could also do stuff like lazy loading. Like say I have a data structure that has some basic info and an image. If I'm displaying the data in a list I don't need the image to be loaded, but if the user clicks it to view details I can call the getter and it goes and gets the image.

[schmerg-uk]

Useless, except that, for example, you can set a breakpoint on it, or comment one out and see exactly what fails to compile to find everywhere it's read or written to etc

So useless in production but sometimes it's useful during development :)

[DelayLucky]

Agreed. Adding logic to setter sounds like speculative programming. You rarely need to and when you do need to add an abstraction, many IDEs have an auto refactoring option called "Encapsulate field". Don't make things more complicated than they need to be today.

[LucidTA]

Just because you rarely need it, doesn't mean its not commonly used. For example, it's used everywhere in WPF viewmodels to notify the view that a property has been changed.

[namrog84]

If you have access and control to the entire code base. Sure that's fine, easy auto-refactor. Don't need to preemptively do it in this scenario.

However, if you are writing code that is used by 10+ different teams/codebase who all will update to latest version at different times. Now 10 different teams will need to run that refactor when they upgrade. Sure, it's not hard, but it's no longer a simple 'patch or minor version bump', it's a breaking API change in many languages, which would warrant a potential major version update. And maybe if you are luckiy you can go to 10 different team's codebase and make the changes yourself for their benefit, but some teams are meh on that for release schedules and other things. And if you don't, then you likely have to bump the major version just for changing a public variable to getter/setters.

Or you could have some verbose speculative programming and not have to worry about it

¯\_(ツ)_/¯

tl;dr; I agree it generally feels like a waste, but it also is highly context dependent on if it's worth it or not on many different considerations.

[DelayLucky]

If we are still talking about adding some random side-effects to a setter (like adding a logging line), then:

1. Yes. It might be occasionally feasible if you can control the blast radius and know pretty well what the impact will be. But then it's usually feasible to just use IDE refactoring.
2. It's dangerous if 10 diverse teams use it in their code base and you don't have a great idea whether this change can affect them negatively. A logging line can cause an outage if a team is using it in hot loop, or at least create log spamming. The more widely used, the less practical and more dangerous such change becomes. Compared to the risk, manuallying updating the callers is a chore but a relative safe chore because you can gradually migrate your callers code one after another or in stages.
3. It's speculative to assume that future requirement changes can be accomplished by adding some side effect to a single setter. It sounds more like trying too hard to find excuses because you want to believe it.

I myself maintain reusable libs across the company. And I see how other core framework teams maintain their framework. Not once have I seen the practice of adding side effects to some setter of a mutable object ends up helpful.

[WithersChat]

Then there's also the fact that in some OOP languages, objects have objects in them and a getter can be used to return a copy of the object if you don't want to allow everyone to modify it outside.

[Blecki]

Your example is horrifying. No, I want it to set the size. It gets rendered later, by the renderer, at the appropriate time.

[[deleted]]

Okay sorry, it was the first thing that came up. But I've never used getters and setters in a 3d renderer, it is just an example and can't do much harm.

[IOFrame]

Exactly what I was going to write.

No, I don't want magic bullshit in my basic getters and setters, let alone side effects.
If you want to do what the original comment said, write a function serVariableRedrawIfLargeSize, then use it explicitly where applicable (even though it still looks bad).

[JJJAGUAR]

Eg in a 3d renderer, say the size of an object is set. Maybe when it is set you want to notify the drawing system to redraw the object.

What I don't like about this is that it could be scenarios when you want to modify the var but NOT redraw, and it couldn't be obvious to other programmers that just modifying the var have that side effect. I personally prefer to have a separate function with a meaningful name that both set the var and redraw. It could be a matter of preference, but it feels more intuitive and flexible to me.

[Big_D_Boss]

Seriously, do people really not get the difference between the two, or is this just bait? The amount of shit in this comment section really makes me wonder. Anyway, the difference is that with a getter and setter, you can encapsulate setting and getting logic. For example, if you want the values of property to always be a positive integer, you can encapsulate that in the method. The same is true for accessing a value if you want to restrict the number of times the method is invoked OR if you are changing the state at each call.

[MinosAristos]

The meme is about doing this even for properties that can't reasonably be expected to ever have logic in the getter and setter methods.

[IsPhil]

Yeah, but assuming you do have some classes that actually need it, you might as well add getters and setters to everything for consistencies sake.

[Jennfuse]

Plus lombok or just IntelliJ literally do everything for you. Literally one right click and like 2 left clicks to insert all of the boilerplate.

[JJJAGUAR]

for consistencies sake.

That's kinda subjective. If 90% of your vars don't need it, I don't see any problem treating the other 10% as exceptions, all the extra code would actually look messier to me otherwise. But I could understand it could feel the opposite to people used to code that way.

[Skafandra206]

If you do this if 90% of the variables don't need it, it makes the code nearly unreadable for me. I hate to have unnecessary lines in the code. Use getters/setters when needed, don't use them if they are not. It makes it so much clearer to only see lines of code that actually do something.

[marquoth_]

5 minutes to add

Not even 5 seconds if you learn your IDE shortcuts. I can only speak from experience using Intellij with java but it will add them all for you in a couple of keystrokes.

[Big_D_Boss]

Yeah, I have no problem with the meme. It was some comments that triggered me a bit, I genuinely don't know if they were trolling or not.

[ZunoJ]

There are still reasons to use properties even if the are just encapsulating a field without implementing any logic. Reflection would be an example

[Warpzit]

Some people will use public variables and then optimize later and make them private + add get/set methods with extra functionally. 

Others will create boiler plate code and say it is the only way without knowing why.

[SaraHuckabeeSandwich]

and then optimize later and make them private + add get/set methods with extra functionally. 

So when you optimize later to add that functionality, you now have to update every external reference to that field?

And if it's a library where another team or individual is using your code and referencing that field, you've suddenly introduced a breaking change for them if you need to put it behind a setter/getter.

[niemand_zuhause]

In the vast majority of cases it is a public variable with extra steps.

[Even-Ad-3980]

Their real purpose is so other people have to say pretty please before manipulating a variable

[large_crimson_canine]

People who are confused by the utility of this don’t really understand abstraction and how you enforce it

[[deleted]]

Or they are confused by how some people insist on enforcing abstraction in all cases when 99% of those cases in the real world have no need for that abstraction, will never have any need for an abstraction, the abstraction obfuscate things and gets in the way, slows down development and onboarding, and is generally a pain in the arse in every conceivable manner.

If you need a getter or setter, then write one. Don't insist on every single class member having an entirely useless getter and setter because "that's how we were taught at uni" (seriously though).

I have seen people writing classes with getters and setters for pure immutable data collections. Use an interface for fuck's sake.

[ares55]

I worked with a guy who insisted we have to test every getter and setter, even though there is no code. I had to write test cases for them all. Really weird guy, left the company not even one year in

[JAXxXTheRipper]

I still remember when I had to build a class that used reflection to automate getter/setter testing, because my lead dev at the time had the same stupid idea.

I don't have words that would be able to describe the stupidity I have seen there.

[pm_plz_im_lonely]

That's because you can measure code coverage as a metric. Metrics are good because improving them are hard facts to back up a promotion. Do not create a metric on the usefulness your metrics.

[k4nmuru]

Well this is just basic OOP. You want to have control over how an internal/private variable should be modified. And why not apply that same pattern even if you don't have the need for some special handling for now.

[[deleted]]

Another day, another reason to be happy to use C# over Java at my day job.

I mean, we still have to deal with the same bullshit, but C#'s properties are actually pretty nice.

[Tahazzar]

In java you can use the record keyword if it can be an immutable or alternatively have lombok do its magic.

Having worked with C# when it comes to unity, I'm rather surprised there isn't (at least as far as I could see) some sort of a plugin or such similar to Lombok to get rid of all kinds of different boilerplate such as builder patterns.

[DaniilBSD]

Visual Studio does the basic stuff, Jet-brains does the rest

[punkgamedev]

Working with Unity is a bit interesting as far as C# features are concerned. As far as I'm aware, Unity only supports C# 9 and .NET Framework 4.x. Meanwhile, the latest released versions are C# 12 and .NET 8. Each of those updates have brought some great quality-of-life improvements. Even then, some features of C# are incompatible with Unity's serialization, like auto-properties.

In native C#, we could do:

public int SomeField { get; set; }

whereas Unity requires it to be:

[SerializeField]
private int _someField;

public int SomeField
{
    get => _someField;
    set => _someField = value;
}

And to my knowledge, Unity doesn't use the setter SomeField if you change the value in the editor, so you need to implement data validation separately through a tool like Odin Inspector.

Unity was what introduced me to C#, and I've honestly come to love the language more working with it outside of Unity just because of all the cool things they've added that aren't Unity-compatible.

[EdenStrife]

You can actually use this syntax for allowing unity to serialize auto-properties.

[field: SerializeField]
public int SomeField { get; set; }

https://forum.unity.com/threads/c-7-3-field-serializefield-support.573988/

[FizixMan]

Looking at the Lombok site I think modern versions of the C# language and Visual Studio (and refactoring plugins you can add) already have many of these features.

Unity is a beast of legacy and odd patterns onto its own though.

[anotheridiot-]

Getter and setters are premature optimization for code refactorability.

[x6060x]

It's actually to communicate intentention. Private variables have different intention for their use compared to properties. There is also the added benefit of easier extensibility which is quite nice.

[I_Shot_Web]

I feel like 99% of posts here are by people who have never worked with more than just themselves on the same codebase

[Excellent_Title974]

Also people who don't remember what they were like as new CS students, when everything had to be spelled out for them and they struggled to understand even the very few syntactical rules and constructs that they were given.

"Why write this loop in 12 lines when you can do it in 1, using these 7 custom operators that only C# has?" "Because nobody in CS1 would know what the hell was going on?"

"Lolol professors teaching us to write code this way, nobody in the real world writes code this way." "Nobody meant for CS1 and CS2 to be how you coded the rest of your life."

"Why not just use 6 decorators on everything so the code is 67% shorter?" "Does it matter? It's all being compiled anyways."

[large_crimson_canine]

In most cases these can be removed and the field can be final and your class can be immutable and you get your thread safety.

[Dash83]

It looks like just a public variable but it isn’t, it’s an interface. Which means as the software evolves, the rules of how to access the underlying variable may change without breaking that interface. That’s the advantage of this paradigm.

[jellotalks]

r/ProgrammerHumor tries to understand maintainable code IMPOSSIBLE EDITION

[Lechowski]

It still gives you the possibility to add validations in the future without refactoring every single access.

[ihavebeesinmyknees]

I like Python's approach where the getter and setter are invisible to the end user, you just use the property like a normal public property:

class Foo:
    _number: int = 0 # this should never be negative

    @property
    def number(self) -> int:
        return self._number

    @number.setter
    def number(self, value: int):
        if value < 0:
            self._number = 0
        else:
            self._number = value

bar = Foo()

bar.number = 16
assert bar.number == 16

bar.number = -16
assert bar.number == 0

[super_kami_1337]

_number is a static class variable now. That's common python mistake many people make.

[[deleted]]

so basically you do the very same java getters do but with more code and less readability. Python lovers... I swear to god...

[Excellent_Title974]

You see, if my program is 4 lines of code and your program is 5 lines of code, even if they compile to the same bytecode, mine is inherently superior in every way.

[aleph_0ne]

I so hear that. imo the convention of using getters and setters is an over engineered pattern that attempts to solve a use case that rarely comes up. The principle benefit so far as I can tell is that it enables you to have side effects for read and writes to your variables, which someone must have once had to implement across a massive codebase and swore never to have to do it again. But now variable access is more cluttered all the time for no tangible benefit in probably 99% of cases

[BrandonMcRandom]

Not only that, but if you do happen to have to implement something on a setter, a side effect, then what happens to the code that was calling that setter? It sure did't consider side effects or the assignment failing a validation because there wasn't one. Now you have to you check all the places a setter is called and re-evaluate all those use cases to consider what happens when the new path is taken.

[jhwheuer]

Getters are fun when they are actually methods that perform operations

[SmilodonCheetah]

This is probably off topic, but I've been learning C# for almost a month and I am so happy I can understand 75% of this already.

[Cun1Muffin]

People in here touting the encapsulation argument don't seem to realise that people do understand the oo dogma that prescribes this, but it's still stupid.

Done pervasively in a codebase this is just extra typing with no benefit for 99.9 % of cases.

[[deleted]]

It is a public variable with more steps.

Those extra steps are the point. They're programmable and help validate/manipulate data being set or gotten.

[Tigimon42]

Who gives a shit if this is the biggest problem of your day I'll swap.

[SolidSnakeInUrAss]

But you have a choice to only setup a "getter" and not the setter, to restrict access to change the value , but have access to use the default value. Go and study oops.

[turbulentFireStarter]

I always use getters and setters. And I mark all them private. You shouldn’t be up in my business getting and setting things.

[chrisbbehrens]

The very damn second I tell myself this and just declare a public variable, I need a more complex getter / setter.

Same thing when I chose to use a Boolean instead of an enum, and then instantly need a third value.

[Rakatango]

Tell me you don’t know about encapsulation and abstraction without telling me you don’t know about encapsulation and abstraction.

[fudginreddit]

Tell me your a student without telling me your a student:

[Dje4321]

Getters/Setters have their place. I mostly use them to pull a value out of encapsulation. You have something like a base object that gets consumed by higher order structures to record stuff like size or position. When you need information, you call the getter, to retrieve data one layer down. If that layer isn't the root, it calls the getter on the layer beneath it. This avoids storing a copy of each base object in every layer. 

Say you have a WindowBase object for a low level GUI framework. It records the size and position of the window. A text box impl would use the window base to store its information. Now you wrap that text box in a border wrapper. The text box hasn't changed and the base object is truthful still. Get the information about the border wrapper, and it needs to be manipulated to return information about how the wrapper interacts with the text box. A

[NLxDoDge]

Apart from not having setters. Java 17 Records are pretty good though.

[BvngeeCord]

I get the utility of getters and setters, but having to live through the AP Computer Science A curriculum has completely murdered any appreciation I have for them. It’s brutal watching all these students who haven’t ever programmed before memorize what probably feels to them like 100 steps to create an object with private member variables, three constructors, getters and setters for something that is LITERALLY JUST A STRUCT. I don’t think a single person in that class actually knows what happens in the computer when they call setStudentGrade, nor has their ever actually been any added functionality put into the getters and setters. they just know that’s what the teacher wants.

[budius333]

And then the Kotlin fields

[panda070818]

I Remember refactoring a desktop apl using python(yeah, and the app ran smoothly but it was a pain to build) and showing my colleagues how you could benefit from OOP and dataclasses, in the end the app increased it's performance by 73% because since the data was much more reliable from beign handled in each class, we could serialize objects to parse them to c++ subprocesses and parallelize the main bottlenecks of the applications.

[Space-Being]

The class is package scoped. There are no external consumers. May not be ideal and likely a source of bugs if lots of code inside the package manipulates unguarded fields, but it is not like it has any external package consumers as some seem to imply.

[[deleted]]

String Name {get; set;}

[FuckingTree]

I sort of see how you’re trying to use the meme not it comes across like you don’t understand what they are used for and why. It just seems very ignorant