I’m trying to get my head wrapped around all the concepts of OOP. I have heard that it is better to use private properties and use getting methods rather then using public properties. It seems like it has the same result but I am trying to understand why one is any better then the other. In the two class samples below I have done it both ways and wanted to see if someone could tell me why the second one would be better then the first one.
class Movie
{
public $movie_id
public $movie_name;
public $rating;
public $genre;
public $director;
public function getMovie($id)
{
$sql = "select * from movie where movie_id = $this->movie_id";
$result = mysql_query($sql);
$row = mysql_fetch_array($result);
$this->movie_name = $row['movie_name'];
$this->rating = $row['rating'];
$this->genre = $row['genre'];
$this->director = $row['director'];
}
}
class Movie
{
private $movie_id
private $movie_name;
private $rating;
private $genre;
private $director;
public function getMovie()
{
$sql = "select * from movie where movie_id = $this->movie_id";
$result = mysql_query($sql);
$row = mysql_fetch_array($result);
$this->movie_name = $row['movie_name'];
$this->rating = $row['rating'];
$this->genre = $row['genre'];
$this->director = $row['director'];
}
public function getMovieName()
{
return $this->movie_name;
}
public function getRating()
{
return $this->rating;
}
public function getGenre()
{
return $this->genre;
}
public function getDirector()
{
return $this->director;
}
}
If it is easier to show the reason with another sample that is fine, I just thought it might make more sense to me this way.
To add on, or if you wanted to send back a default value for unset or null properties to present a consistent experience to the user encapsulating or utilizing your object. Another common usage is to indicate that the class is “dirty” meaning, it needs to update the database because someone updated a property using a setter.
Your first example implies there is no contract with the end user of this class (imagine you work in a team, and you are only there for 3 months).
This means anyone can purposely, or accidentally do this:
$a = new Movie(23);
$a->movie_name = "Any old crap";
They could even accidentally do this by extending this class in ways you had not originally imagined.
Your second example makes it clear that nobody can set movie_name, and the only way to get movie_name is to call the appropriate method.
What is more, if you or they extend that class then they also cannot gain access to those members without using your carefully crafted methods.
So, amongst all the other reasons why you would use getters and setters you are also signalling your intent to others, and in doing so you are to some degree (some would say to a great degree) you are documenting what you have done.
Hope this puts get/set into some context, but be aware that they should be used wisely [google]are getters and setters evil?[/google]
the text book reasons for getters and setters is encapsulation, meaning that you can keep variables private from outside tampering so that they are never invalid.
Unless you have a specific need for them don’t, the less code the better.
The difference between reading and inquiring properties.
It’s about the answers.
The public properties will be easily read by everyone, no questions asked.
The protected properties, everyone will have to inquire to get an answer.
It’s also about the questions.
The question one is asking may not be so straightforward.
The answer to that question could be a little more complex and it may not be held in one single property.
Part of the reason is data integrity – a setter method can check values before allowing a property to be set. Part of the reason is complex setter behavior – setting one property might include setting another property. For example, setCreatedOn might also call setExpiresOn. And another reason is future maintenance. When you first built your app, maybe you didn’t have an expiresOn property, so you thought it would be safe to set the createdOn property directly. But as your app evolves, and now setting createdOn needs to do more work and therefore needs to be changed to a setter method, that means everywhere in your application where you accessed the property directly needs to be updated. It would have been a lot easier on yourself if you had just made it a setter in the first place.
Setters can include validation to ensure that the content is always valid when stored and that any other criteria for being allowed to update the value are also met.
Getters can be use specific and provide the required escaping when required.
Also it allows you to use any internal format you like - a simple example would be a date field where the internal value is often stored as a number and the getters and setters convert between that internal number format and the various formats that a date might be in.