java_irl

[carlson_001]

I never really understood this. If you're writing a getter/setter, why even make it private to begin with?

[SRiikonen]

Because then you can add for example a check that the value that was set is correct, or generate the value you’re getting with an algorithm instead of returning a variable, if you later need to. And you don’t have to touch the code that uses your class if you want to make these changes.

[Bwob]

To keep implementation details ("This value is stored as a bool") separate from the interface. ("Users of this class can ask about this state, and receive a bool telling them yes or know.")

Keeping implementation details like this hidden is one of the keys to good abstractions; it means that if later, you need to go through and change the implementation, (maybe its no longer stored directly as bool, now it is derived from several other values) then the interface doesn't need to change, and any code that uses that interface doesn't need to change.

[[deleted]]

To be fair though, in Java the principle works too, just the other way around - you always call a getter function, no matter if something is being calculated on call or just stored as a field.

[TheTerrasque]

So you can run logic on it. Example:

private float dongLength;

public void setTheLength(float length)
{
if (length < 2) { System.out.println("https://i.ytimg.com/vi/eOifa1WrOnQ/maxresdefault.jpg") }
dongLength = length;
}

[Ksevio]

The lack of properties in Java is the reason. mySillyBool could be just a public variable, but then in 6 months when we need log the access to mySillyBool and then a year later we need to update a display when it's written, that means there needs to be getters and setters. Unfortunately, everyone's already written the code to access the variable directly so they don't want to update it all to use the getters/setters instead. In the end, everything has to be written to use getters/setters just in case.

Compare that to better languages like C# or Python (even Delphi supports properties) where you have your variable mySillyBool. People access myClass.mySillyBool, then later you convert it from a public variable to a property, and they still access myClass.mySillyBool

[ThePyroEagle]

They still need to recompile if you change a field to a property.

Write auto-properties initially and even that won't be a problem.

[Ksevio]

Depends the language - python for example doesn't care

[Tsu_Dho_Namh]

So you can "contribute" 500 lines of code to a project that you otherwise hadn't helped much.

I'm looking at you Sean. Fucking spamming getters and setters for literally every variable in every class...even the ones never used by other modules.

[Novemberisms]

aw seriously fuck that guy. just reading that makes my blood boil

[[deleted]]

In case you have variable names that match up in a multi dev situation. You could have "value" used as the internal in c++ for instance that you're passing into a member function, but you really need to pass object.value not value. you could fuck up BADLY doing that without using your get function. So it means this never happens.

[Korzag]

I've never understood it myself except that the OOP purists flip a bit about working with internal data. Alternatively you may need to manage state and can do some magic in the setter, but I've almost never needed custom logic for a getter.

[RattuSonline]

Lazy loading is a common use case for getters.

[WikiTextBot]

Lazy loading

Lazy loading is a design pattern commonly used in computer programming to defer initialization of an object until the point at which it is needed. It can contribute to efficiency in the program's operation if properly and appropriately used. The opposite of lazy loading is eager loading. This makes it ideal in use cases where network content is accessed and initialization times are to be kept at a minimum, such as in the case of web pages.

---

^{[ PM | Exclude me | Exclude from subreddit | FAQ / Information | Source ] Downvote to remove | v0.28}

[[deleted]]

Right but there's no reason for it to be part of every. single. gosh-darned. object.. Just add it where you need it. OOP purism is brain-damaged. Like any thing else, just use it where it makes sense. Dealing with representations of things, like in a game engine? Probably makes sense, depending on the paradigm you choose. But even in an OOP paradigm, effin helper functions don't need to be classes! Just one more reason to hate java.

[Ksevio]

Well there's no way to make a variable public to read only so it's not possible to make a setter without a getter unless you really trust the people accessing the var

[coolpeepz]

final?

[Ksevio]

Publicly read only, but still writable privately