Justification, positives and negatives of variable-managing functions

Unity Engine
1

I was wondering about following variable management:
Note, psuedo-code:

string myString1;
int myInt2;
bool myBool3;
List<Player> Players4;


public void SetString(string newStr) {
   myString1 = newStr;
}

public string GetString() {
   return myString1;
}


public void SetInt(int newInt) {
   myInt2 = newInt;
}

public int GetInt() {
   return myInt2;
}


public void SetBool(bool newBool) {
   myBool3 = newBool
}

public bool GetBool() {
   return myBool3;
}


public Player GetPlayer(string name) {
   foreach (var player in Players4) {
       // And some other extensive testing
       // if (blabla == blabla)
       // EpicFunction();
       // StartCoroutine(other);
       if (player.name == name) return player;
   }
}

And here are couple questions that follow:

  1. Do you believe the example provided to be programmatically acceptable? I.e. there’s multiple programmers working on a single project, would such usage improve/decrease or keep the same readability and program flow?
  2. Do you believe a significant (not as an exception) amount of situations which would benefit from the example above compared to regular direct assignment? Could you eventually provide minor examples where you yourself would see yourself using functions above instead of regular direct assignment?

By “regular direct assignment” I mean: myString1 = "You're the wizza Hawwy!";

Edit: Removed public property from variables, my bad.
Edit2: get/set is unfortunately not the solution to my assessment.

2

Sounds like you just want to set up properties. But as you have it now, no. You would not want public fields if you wanted to include methods to access them, otherwise people could bypass your methods and just access the fields directly.

As to why you use a getter/setter, it’s pretty simple. If you deal damage, you want it to also calculate if the target is dead, and if not, set the value. Or if you change status effect or something like that.

Or imagine a bank atm that didn’t check your bank balance before given you your requested withdraw. There are a bunch of use cases for not setting fields directly.

Anytime you need to do something with the value before assigning it or accessing it, you’ll want to avoid letting direct assignments.

3

Using methods to get/set the values of variables is such a common thing that C# created a special language feature specifically for that: properties.

The usual purpose of such functions is to enforce constraints on the variable (prevent it from being set to an illegal value) and/or to cause other code to run automatically when the variable changes (e.g. recalculating related variables, or firing off events to let other code know that something has changed). If you are 100% sure that you are never going to do either of those things, then you could probably just use public variables instead.

4

I’m 100% sure I will need a lot of such variables. But I also need to pass a variable or two along to have it process properly. Unfortunately get/set is out of question, I consider it too much hassle. Variable can disguise its process a function cannot.

5

Getters and setters are essentially useless. It’s essentially guarding against having to refactor in the future, in case you maybe want setting or getting those values to have a side-effect. You generally never want to do that, because a thousand small bloats of your program just in case becomes a lot of bloat real fast.

6

Can’t figure out what you’re trying to say here.

7

Sorry, my bad.

When you use get/set, there’s no parameters to pass through, and sometimes you can overlook variables that have internal processing. (In editor) It’s harder to distinguish between a variable which has get/set defined from other variable that hasn’t - there’s minor difference without directly looking up given variable - than an independent function that tells you “I’m going to change this variable/list/dictionary to this”.

8

I take it you are thinking of getters and setters and do nothing except return/assign a variable. (I usually hear those terms used in a way that includes functions that have other processing or side-effects.)

9

If you have a function that requires additional parameters, or whose primary concept is NOT simply to get or set a specific value, then we’re out of the domain of getters/setters and just talking about functions in general.

Also, terminology note: “a variable which has get/set defined” is not actually a variable, it’s a “property”. Properties look like variables but act like functions. They can’t do anything that you couldn’t do with a regular function; they’re purely a way of making functions that “look like” variables.