DEV Community

Discussion on: Avoid getters and setters whenever possible

Collapse
 
pocketstealer profile image
Pocketstealer

Get/Setter.

Why? Because it's easier to say in a set:
If(Value not null){
set value
}
else{
w/e
}

Than to go EVERYWHERE and check if that value is null then use something.

Sure a basic example looks stupid... but you were not taught not touching the flames by being explained what thermodynamics are...

Get/Setter's are better for a good approach and have assurance that the class will work no matter what the values will be given.

PHP is a loosely typed language getter/setter are perfect for this.

Collapse
 
scottshipp profile image
scottshipp

You're concerned about code duplication and that's a good concern. But what if there's a bigger issue here? The fact that this setter can be called "EVERYWHERE", as you say, is a bigger problem to me. Everyone has access to set this value. If just one of them makes a mistake, everyone else using it suffers the downstream effects.

So the real problem here isn't duplicated code, to my mind. It's the fact that there's a variable available everywhere. That sounds like a global variable with some procedural code manipulating its state.

Consider what happens if the field is kept private, and no get/set methods are made public either. Where is everywhere now? Only inside the class itself. It's not a global variable anymore. There aren't a bunch of random classes out there that can go set that value. Another developer can't come in with some new code that calls set on that value incorrectly, and stops several user scenarios from working correctly.

I think we've all worked in scary code like this and we can do better. In my experience, I've found that looking at everywhere the set method is called yields the result that I come out with at most a few different uses, and I can write a method for each use and call the new method from these call sites instead. They'd be behavior methods which keep that variable inside a class or at worst inside a package, and not available everywhere. That way I not only de-duplicate code, but I prevent other bugs that could occur as well. Bugs like the site header one that I mentioned. When no one can call setWhatever(newValue)--indeed they don't even know that the Whatever variable exists--then those kinds of things aren't possible.

Collapse
 
jstormes profile image
James Stormes

In PHP we also use reflection for hydrating objects. If all your objects properties have getters and setters you can hydrate by reflection, otherwise you have to write lots of exchange_array code.

However we can also hydrate on properties directly, but you don't get to do any validation of the data. As you say PHP is loosely typed, so that opens you up to hacking/injection.

What is harder to do is hydrate on both get/set and properties. So you wind up all ways using setters, even if you don't need them all the time.

Collapse
 
pocketstealer profile image
Pocketstealer

I think we are confusing bad practice with the role of getter/setter.

Bad practice is everywhere. But when you are using a getter/setter you expect to give a certain value and get a certain value.

You know you are setting a string. You will get a string. Thats the role of the getter/setter.
You are certain and sure that there will be in no circumstation a null there. Or a number. Always a string.

Using getter/setter for everything is bad as well. Leaving a variable there that is used and can be moddified to contain anything is even worse.

If you use get/set just to "return","$this->alfa = value" that's bad practice.

But a beginner doesn't know when should use it or not. So the one that's easiest to "implement after" it's the cheapest.

Scope of projects change. Agile is here and not always you have time to get all the information/specs or maybe some new information get there with constraints.

Always take the safest/easiest way rather than "smart way but it might blow up later".