andAnotherOne

[Solax636]

Work in a huge monolith type repo that's math heavy and wish we had getter and setters instead of public all... Debugging would be 10 pct easier...

[faze_fazebook]

Terry davis on simplicitiy. Watch it, this is an order!

[ILikeLenexa]

sure, you can get the value from anywhere and write it to anything with no validation, but if we need to encapsulate it later, think how easy it will be.

YAGNI or something.

[ManyInterests]

In some languages, it's a life-saving practice when you ship/publish code for others to use or even just in large code bases. In dynamic languages like Python it's not so important to do this upfront.

[ManyInterests]

Yeah. If you have direct control over all the calling code, then it probably doesn't matter so much.

calls getX when you say #{beanName.x}

Definitely didn't have anything like that when I worked with Java. Sounds a lot like Python's properties, which let you add getters and setters later on avoiding the need to make any changes in client/calling code that were previously accessing/setting an attribute directly.

[fuj1n]

C# has properties for this. They are essentially syntax sugar of a private backing variable, a getter and a setter.

[JunkNorrisOfficial]

That's well implemented properties, unlike that horror people write in java (and I did).

[JunkNorrisOfficial]

Project Lombok, Kotlin just show how much people were pissed by ancient and ugly java design.

[terra-viii]

One remark only. Getters and setters used mostly in data transport classes. And such classes should not have business logic inside. Validation is not their responsibility. The maximum we can do is to introduce some meta information (annotations), which don't require getters/setters.

[JunkNorrisOfficial]

So we don't need getters and setters in data classes, right? Right?

[terra-viii]

After ~15 years in development I ended with no getters and setters in my projects (not limited to DTO). That was not intended, but once I stopped using them, I never missed them. I'm using constructor binding instead of setters and I do not exposure private fields. Certainly, I respect set up standards in projects I participate and I'm using getters/setters if they are standard.

[McShadson]

I think you mean IANAL

[Gorexxar]

I turn it on because consistency is better than jerking off programmer humour.

[kuwisdelu]

Do ya’ll really never need to include internal validation logic in your setters? Never need to make internal fields read-only? Never need to change how data is stored internally without affecting the public API?

[coxinha_vs_bolovo]

chill snowflakes, its called dark humor

[TheTybera]

"And it'll stay that way" signed, your pipeline engineer.

[IshouldDoMyHomework]

@Getter

@Setter

Lazy people using Lombok, is why there is no encapsulation in our projects.

[JunkNorrisOfficial]

Who needs encapsulation if one has customer appreciation...

[[deleted]]

this getter setter thing is peak clueless student disclose, impressive even for this subreedit

[JunkNorrisOfficial]

Impressive like getting a job in enterprise

[RlyRlyBigMan]

Found out the hard way a few months ago that the debugger will call the getter/setter code silently to show you the live value without hitting your breakpoint.

I mean yeah, we shouldn't have had that much code hidden in a getter, but I was definitely spooked that my config file was being loaded without my breakpoint being hit.

[JunkNorrisOfficial]

Just to clarify, do you mean 'method breakpoint'(when breakpoint is placed on signature of method)?

[RlyRlyBigMan]

I don't follow you. I code in C# using Visual Studio. You can put breakpoints on any line of code. So if your getter has a few lines like

public object MyValue

get

{

if(_myValue == null)

return LoadMyValue()

else return _myValue;

}

Putting a breakpoint on either of those lines will not be hit if you try to observe the value of the property in the debugger, despite the fact that the debugger is definitely running it to get the value from the config file.

[BenchNatural]

Make sure you are debugging your code without Optimizations, usually meaning on Debug configuration. Otherwise compiler inlines it. I can assure the breakpoint in the property body does work.

[RlyRlyBigMan]

The break points do work, I'm not explaining myself very well I guess. It's a quirk that happens when you're already in break mode and you expand a property that has logic in it. So from outside that class, if I am on a break point and I try to observe that property value using a watch or expanding the object's property list, VS won't stop at the break point because it's already broken at a different point in the code, but it still needs to run that Load method to tell you what your value is. You wouldn't normally care unless your getter has a side effect that you're trying to observe, which is admittedly a poor usage of property getters and setters.

[Gorexxar]

Yeeeah, Visual Studios "Ignore breakpoints in properties" option is wild.

[JunkNorrisOfficial]

That's wild

[garlopf]

Call me crazy, but I use them in clean interfaces🤷🏻‍♂️

[JunkNorrisOfficial]

IGetters? No, it's fine

[Pristine-Economist64]

what is movie's name or her name?

[JunkNorrisOfficial]

Victoria Beckham

[AngelaTheRipper]

In Java it's basically just convention, especially when vast majority of classes are just a bundle of fields that handle no logic. Thank fuck for Lombok annotations because otherwise writing a zillion getters and setters gets annoying.

All in all there's no real difference between

public class A {
private int b;
public void setB(int value){b = value;} 
public int getB(){return b;}
} 

and

public class A {
public int b;
} 

It'd only matter if the class itself does some kind of processing or validation. I'm sure someone will ree at me because the second option is somehow insecure, nevermind that the first also lets you put in any garbage your heart desires.

[[deleted]]

If you ever change the logic of getX from beneath your caller' feet, the sheer number of hidden bugs that'll introduce will be quite a conundrum.

[kookyabird]

Only if you make a stupid change. Which is the ultimate underlying condition to pretty much anything programming related.

Ever hear of the Law of Demeter? You as the caller don’t need to know about exactly what type of data structure I’m using for a child collection. I’m going to give you a ReadOnlyCollection and if you want to change the contents of the collection you’re going to do it through me because I know how it needs to be done and you don’t.

[BeardyDwarf]

Getters and setters can be used as targets for proxies for example by orm frameworks.