Why is get/set properties recommended?

[silkfire]

I wonder why one should use get/set with private property when working with classes instead of creating a public variable that you can modify?

 

$obj->testvar = 'New value';

 

seems easier than:

 

private $testvar;

public function setValue($new_value)
{
    $this->testvar = $new_value;
}

public function getValue()
{
    return $this->testvar;        
}

[Jessica]

You may need to have some processing that gets done to the variable every time, like checking it is the correct type.

[silkfire]

But if it's purely for get and set? Calling a function is overhead, right?

[MMDE]

But if it's purely for get and set? Calling a function is overhead, right?

 

That really depends. If this is some small code you're doing alone, then it doesn't really matter. It is usual practice in OOP.

[Mahngiel]

get/set is newer to me as well, but I do believe having public variables is also a concern that they could be overwritten by children causing unwanted consequences down the line.  this is why i believe it's best practice to have each child / caller use gets and sets since it applies to scope only.

[yamikowebs]

Getters/Setters are good practice for a few reasons and depend on your programing environment to make full use of them.

 

1) It creates an access point which is easier to identify and track when you have multiple objects interact with other objects. It also allows you manipulate information before it goes in or out of the class automagicaly or trigger an event if you have your own event system.

2) If you are using an IDE like netbeans type hinting adds another benefit. You type object->Set and a list of what you can set show up and the same for get. This is more so helpfull when you have multiple people working on a project with a library they are not very familiar with. It is quicker to look at set and get and properties than a huge list of properties although this is arguable.

 

Here's a great link on it with C++ that a friend shared with me awhile back when I asked him the same thing.

http://www.zeuscmd.com/tutorials/cplusplus/50-GettersAndSetters.php

[ignace]

There are some use scenario's where getters/setters are not a real option like when a class would hold over 1024 properties that are changed by users (or the system itself) in different parts of a system which is common for big data projects (like for example all attributes of a house).

 

If anyone has any pointers for me on these scenario's, please share them with me as currently it all goes through $o->set($name, $value).

[Mahngiel]

If anyone has any pointers for me on these scenario's, please share them with me as currently it all goes through $o->set($name, $value).

 

My (limited) experience and reading says that's a much better plan than having individual getters/setters. Specialized setters/getters could always be drafted.

[Tarential]

As a simple example of why it is good practice, I present you with the following scenario: You have an object set as a class property. Within your code, you assume that any time you reference this property it will respond as the object. With proper get/set functions your code can ensure that nothing but a compatible object may be assigned to that property and your code will always function without error.

 

Now assume that instead you had used a public class property. At some point you or someone else assigns this property to a new object which is incompatible with the code and your program starts failing with PHP errors. With a proper set method it would return an "invalid object" error code which can in turn be logged instead of displayed to the user. This makes debugging easier and makes your program more robust.

 

This is just one example of many situations in which proper get/set methods are useful.

[yamikowebs]

Its in situations like your where I think setters and getter are the most useful. with

$o->Get($name, $value)

I as a new programmer on the team would have no idea what the properties are and what they do. However If I want to get Something with setters and getters I just type

&o->Get

and all of the things I can set will pop up in my IDE with notes on what they are for, accept, and return. you can do this with public properties but there's a few  reasons as to why you want your properties to usually be private or protected. It can cause issues in certain situations which I can not remember of the top of my head.

[xyph]

Its in situations like your where I think setters and getter are the most useful. with

$o->Get($name, $value)

I as a new programmer on the team would have no idea what the properties are and what they do. However If I want to get Something with setters and getters I just type

&o->Get

and all of the things I can set will pop up in my IDE with notes on what they are for, accept, and return. you can do this with public properties but there's a few  reasons as to why you want your properties to usually be private or protected. It can cause issues in certain situations which I can not remember of the top of my head.

 

That example is specifically targeted at classes designed to hold huge amounts of data, where a getter/setter for each mutable property could result in thousands of methods needing to be held in memory. In that case, it's better to have a generic getter/setter for all properties, rather than one for each or none at all, IMO.

 

There are some use scenario's where getters/setters are not a real option like when a class would hold over 1024 properties that are changed by users (or the system itself) in different parts of a system which is common for big data projects (like for example all attributes of a house).

 

If anyone has any pointers for me on these scenario's, please share them with me as currently it all goes through $o->set($name, $value).

[yamikowebs]

Its in situations like your where I think setters and getter are the most useful. with

$o->Get($name, $value)

I as a new programmer on the team would have no idea what the properties are and what they do. However If I want to get Something with setters and getters I just type

&o->Get

and all of the things I can set will pop up in my IDE with notes on what they are for, accept, and return. you can do this with public properties but there's a few  reasons as to why you want your properties to usually be private or protected. It can cause issues in certain situations which I can not remember of the top of my head.

 

That example is specifically targeted at classes designed to hold huge amounts of data, where a getter/setter for each mutable property could result in thousands of methods needing to be held in memory. In that case, it's better to have a generic getter/setter for all properties, rather than one for each or none at all, IMO.

 

There are some use scenario's where getters/setters are not a real option like when a class would hold over 1024 properties that are changed by users (or the system itself) in different parts of a system which is common for big data projects (like for example all attributes of a house).

 

If anyone has any pointers for me on these scenario's, please share them with me as currently it all goes through $o->set($name, $value).

 

yes it is slower but its a question of how fast does it need to and if this would be the bottleneck. Most likely it wouldn't be. If speed is important then PHP isn't the best language to be using. Compiled non OOP languages are faster.

 

1k+ properties is a lot and I would imagine you should be breaking your object down into multiple objects and have an object wrapper or builder pattern. Do you really need 1k+ properties every time you need to do something with the class?

[ignace]

1k+ properties is a lot and I would imagine you should be breaking your object down into multiple objects and have an object wrapper or builder pattern. Do you really need 1k+ properties every time you need to do something with the class?

 

Well in the house example I was thinking of breaking it down into Kitchen, Bathroom, Bedroom, .. which would all become part of a giant composite tree (House as parent) but before going down that road I wanted to see how the current design played out.

 

I don't need all the data all the time, and I also only load whatever is required at a particular point. Actually it's a proxy (wrapping a DAO) so that if I ever would need extra data, I can still get it.

 

I should also mention that the design currently works on 2 different schema's. DB and XML. 3rd party sources send us an XML which are translated to the proper objects and is synced between the XML they send us and the DB.

[tibberous]

Why is putting your hot dog in the bun better than putting the bun around the hot dog?