Home » Php » php – The advantage / disadvantage of private variables?

php – The advantage / disadvantage of private variables?

Posted by: admin July 12, 2020 Leave a comment


I’m used to make pretty much all of my class variables private and create “wrapper” functions that get / set them:

class Something{
  private $var;

  function getVar(){
    $return $this->var;


$smth = new Something();
echo $smth->getVar();

I see that a lot of people do this, so I ended up doing the same 🙂

Is there any advantage using them this way versus:

class Something{
  public $var;
$smth = new Something();
echp $smth->var;


I know that private means that you can’t access them directly outside the class, but for me it doesn’t seem very important if the variable is accessible from anywhere…

So is there any other hidden advantage that I missing with private variables?

How to&Answers:

It differs from case to case if you want to use private variables with public getters and setters or if you just want to declare a variable as public directly.

The reason it might be good to use “getters” and “setters” is if you want to have control over when someone accessess the data.

As an example, lets say you got this:

public setBirthday($date)

Then you can make sure that the date passed in to that setter is a valid birthdate.

But you can’t if you just declare the variable as public like this

public $birthday;

Based on comments.

Also, if you decide change the
internal storage mechanism from a
string containing the date to the
number of seconds since 1/1/1970, you
can still present the date externally
in the same way if you use
encapsulation, but not if you expose
the variables directly. Every piece of
code that touched the internal
variable directly would now be broken.

This means that if the internal storage mechanism would change to numbers of seconds from 1/1/1970 then you don’t have to change the ‘External API’. The reason is because you have full control over it:

public getBirthday() {
  // you can still return a string formatted date, even though your 
  // private variable contains number of seconds from 1/1/1970


It’s called encapsulation and it’s a very good thing. Encapsulation insulates your class from other classes mucking about with it’s internals, they only get the access that you allow through your methods. It also protects them from changes that you may make to the class internals. Without encapsulation if you make a change to a variable’s name or usage, that change propagates to all other classes that use the variable. If you force them to go through a method, there’s at least a chance that you’ll be able to handle the change in the method and protect the other classes from the change.


Access modifiers don’t make a whole lot of sense in scripting languages. Many actual object-oriented languages like Python or Javascript don’t have them.

And the prevalence of naive getter/setter methods is simply due to PHP not providing an explicit construct for that. http://berryllium.nl/2011/02/getters-and-setters-evil-or-necessary-evil/


It is to demark variables that are internal to the implementation of the class, from variables that are intended for external change. There are also protected variables, which are for internal use, and use by extensions to the class.

We make the variables private so that only the code within the class can modify the variables, protecting interference from outside, guaranteeing control and expected behaviour of the variable.


The purpose of encapsulation is to hide the internals of an object from other objects. The idea is that the external footprint of the object constitutes it’s defined type, think of it like a contract with other objects. Internally, it may have to jump through some hoops to provide the outward-facing functionality, but that’s of no concern to other objects. They shouldn’t be able to mess with it.

For example, let’s say you have a class which provides calculations for sales tax. Some kind of utility service object, basically. It has a handful of methods which provide the necessary functionality.

Internally, that class is hitting a database to get some values (tax for a given jurisdiction, for example) in order to perform the calculations. It may be maintaining a database connection and other database-related things internally, but other classes don’t need to know about that. Other classes are concerned only with the outward facing contract of functionality.

Suppose sometime later the database needs to be replaced with an external web service. (The company is going with a service for calculating sales tax rather than maintain it internally.). Because the class is encapsulated, you can change its internal implementation to use the service instead of the database very easily. The class just needs to continue to provide the same outward facing functionality.

If other classes were mucking around with the internals of the class, then re-implementing it would risk breaking others parts of the system.