Avoid Getters and Setters?

[Baronen]

Google has updated their "Let's make the web faster" PHP article.

 

They have now added that you should avoid Getters and Setters and set the value directly to the property. What do you guys think about that?

 

I use getters and setters very often, i think you get a much cleaner code, altough i have never done any performance tests.

 

When writing classes in PHP, you can save time and speed up your scripts by working with object properties directly, rather than writing naive setters and getters. In the following example, the dog class uses the setName() and getName() methods for accessing the name property.

 

Read googles suggestions at http://code.google.com/speed/articles/optimizing-php.html.

[Mchl]

I'm guessing this saves like 1 second on 10 000 000 runs.

 

See here:

http://www.brandonsavage.net/micro-optimizations-that-dont-matter/

[jcombs_31]

As I recall, some of this article has already been disproven, for example copying variables does not consume more memory.  Using getters and setters as far as I was taught is good practice and the technically correct way of getting and setting object variables.

[dgoosens]

it does not make sense to use that kind of setters and getters if you implement them both as they show in the example.

Just using a public variable works...

 

Thus using both of them in a same class just introduces useless extra lines and this should be avoided.

[Mchl]

You might just as well utilize __get and __set magic methods.

[dgoosens]

You might just as well utilize __get and __set magic methods.

obviously, as long as you make sure that they are well written and can not be used otherwise than you intend them to...

 

[Highlander]

I always use setName() and getName() since I believe that the __get and __set methods removes the clarity of what types of properties an object have. I know that __get and __set can create a more dynamic structure, but that is the price I pay for a clearer code.

 

[Daniel0]

it does not make sense to use that kind of setters and getters if you implement them both as they show in the example.

Just using a public variable works...

 

Thus using both of them in a same class just introduces useless extra lines and this should be avoided.

 

Yeah, but nobody writes code like that anyway. It's an example that wouldn't appear in real applications.

 

You might for instance make sort of integrity check, or you might later want to abstract it away using a strategy or you might want to use a proxy. You cannot do that if you're directly accessing your properties.

[Jarod]

Thats seems good to me, but I get the feeling that it might twist something up causing a error with the script it's consumed and associated with. 

[Alex]

The standard or 'correct' way to do it is to use getters and setters.

 

The use of getters and setters, and many other programming standards, isn't necessary for you. It's for other programmers. Other people using your code shouldn't have to understand how everything works internally. They should just have to understand what method X, and what method Y does. Even though you're not going to be sharing your code with other programmers it's good to stick to a constant way of doing things, it will only help you. If you come back to this class 6 months later are you going to completely remember exactly how everything works? Chances are you won't, so it's better to make things easy to use.

[448191]

That guy should be shot on sight. I cannot believe Google lets people publish crap like that.

[corbin]

That guy should be shot on sight. I cannot believe Google lets people publish crap like that.

 

 

Yeah, I remember someone talking about the badness of that post before.

 

 

*Searches*

 

 

http://www.phpfreaks.com/forums/index.php/topic,258236.0.html

[xangelo]

I'm guessing this saves like 1 second on 10 000 000 runs.

 

See here:

http://www.brandonsavage.net/micro-optimizations-that-dont-matter/

 

I'm sure something like that makes perfect sense for Google however. Micro-optimizations don't commonly have a place in regular day-to-day programming projects, but when you're dealing with hundreds of thousands of users, then every little bit will help.

[Mchl]

When dealing with large number of users microoptimisations are not that helpful either.

If you have bottlenecks in your I/O changing double quotes to single will not bring any meaningful difference for end user, and as such is pointless. You should deal with the bottlenecks you have, not ones you think you have.

[Daniel0]

I'm sure something like that makes perfect sense for Google however. Micro-optimizations don't commonly have a place in regular day-to-day programming projects, but when you're dealing with hundreds of thousands of users, then every little bit will help.

 

Unless you've profiled your code, you generally shouldn't start optimizing. Of course you should avoid obvious stupidities though.

[Koobi]

it does not make sense to use that kind of setters and getters if you implement them both as they show in the example.

Just using a public variable works...

 

Thus using both of them in a same class just introduces useless extra lines and this should be avoided.

 

Yeah, but nobody writes code like that anyway. It's an example that wouldn't appear in real applications.

 

You might for instance make sort of integrity check, or you might later want to abstract it away using a strategy or you might want to use a proxy. You cannot do that if you're directly accessing your properties.

 

i was thinking about that too...what if you decide to do some kind of processing before you set or get a method.

 

 

i think getters and setters are good practice based on the situation.

for example, if you're setting values to insert into a database, i think it's alright to set the values to the property directly because and processing that has to be done to a variable before entering it into the database should be dealt with in the model (if you're using the MVC pattern).

 

that's probably the only instance where i'm on the fence about getters and setters.

 

 

google is weird sometimes...their creativity level is awesome but the way they code some web apps just don't make sense. maybe i'm missing something because most of them are probably pretty damn smart.

[roopurt18]

C# gives you the best of both worlds.

 

From the standpoint of client-code, your objects appear to have public properties that you can just assign or retrieve from.

 

However, they are implemented as getter and setter methods so you can perform any type of manipulation or validation that is necessary.

 

I'd like very much to see this feature in PHP.

[Daniel0]

There is an RFC for it:

http://wiki.php.net/rfc/propertygetsetsyntax

[roopurt18]

Mmmmmm.  Thanks for pointing that out Daniel0.

[keeB]

Tell. Don't ask.

[Mchl]

There is an RFC for it:

http://wiki.php.net/rfc/propertygetsetsyntax

 

Very nice. PHP7 or 8 ?

[Daniel0]

Anyone can make an RFC, so it's not certain that it'll be implemented at all.

[Mchl]

Seems it's been discussed at php|tek in Chicago this year. I think I'm going to dig up a little trying to find what were people's opinions on this.

[ttocskcaj]

What harm can actually come from NOT using getters and setters?

I've read several articles that say you must use them or bad stuff will happen. What bad stuff?

 

I know they help make the code more readable, but they also take up a lot of lines of code. And unless you use and IDE that can generate them for you, they also take a lot of time.

[KevinM1]

What harm can actually come from NOT using getters and setters?

I've read several articles that say you must use them or bad stuff will happen. What bad stuff?

 

I know they help make the code more readable, but they also take up a lot of lines of code. And unless you use and IDE that can generate them for you, they also take a lot of time.

 

Not having them can break encapsulation.  Objects should be interacted with through clear lines of communication.  Having an accessor method ensures that the entity interacting with them is, in fact, intending to interact with them and is doing so in a certain, explicit manner.

 

Like someone else said in the thread, they're not for you but for others who will be working with your code.