Why use getters and setters in PHP?

Can anyone clarify in laymans terms, the importance of using getters and setters in PHP? other than for the purpose, of getting and setting a data in php?

As in this example:

class foobar{
    private $foo;

    public function getfoo() {
        return $this->foo;
    }
    public function setfoo($foo) {
        $this->foo= $foo;
    }
   
}

Code (markup):

I assume, the one time I would use it for, is to set a property to value, and just get that value, but it seems the subject of getters and setters in more than that, but I can't see it.

 

Another reason would be when the properties aren't public or you want to limit the user to only set and/or get.

 

Setters also allow you to control the value that's being assigned. Let's say you have a file upload class, and it only supports certain file types. With a setter you can make sure that only supported types are given:

public function setExtension($extension = 'jpg')
{
    if (!in_array($extension, ['jpg', 'png', 'gif'], true))
    {
        throw new Exception('Unsupported type');
    }

    $this->extension = $extension;
}

PHP:

Without the setter, any extension could be provided, and that could cause problems elsewhere in your code.

EDIT: In this example, you would have to make sure that $this->extension is a protected property, so no one can assign a value to it without the setter.

 

Aka restricting scope. Something important in an interpreted / scripting language. Really I'm not a fan of setters as they pretty much defeat the purpose; if you have a 'setter' it should NOT be something that the value is passed to, and instead should pull the value from a static set (like a database). Doing it that way means you can make 'read only' variables that are scope restricted.

Restricting scope limits what script injections can do should they (god forbid) occur -- It's why you aren't supposed to over-use global scope and NEVER put anything security related in same -- see why Turdpress' idiotic "Let's put the sql host, UN and PW in DEFINE" is one of it's biggest security holes, since even a minor injection in the blasted themes or a plugin can have full access to EVERYTHING. It's like locking the doors with the windows open.

 

Yeah, I can see it clearly in your example, but my question is: Why specifically should getters/setters come in, two pairs of function?
Why can't it just be a protected property inside a class, like this:

class foo{
  protected  $bar =  '';
  protected  $tar =  '';
  //..
}

Code (markup):

Then, whenever you need to assign something:

$o = new foo();
$setBar = $o->bar = 'barValue';
$getBar = $setBar;
// the same logic can be applied, when extending another class too. 

Code (markup):

?? It is likely, that this may be the a retarded idea you've seen in a while, but I don't know, why we need explicitly, a function to get/set anything?
I think I am missing something here.

 

Try out the code you posted. It won't work, because you cannot assign protected properties from outside your class (unless you're extending said class). If you have properties that should not contain anything but a specific set of values, or an instance of a specific class, you'd preferably use a setter method.

Let's take a caching class for example. You have one class that supports multiple caching engines (methods): Memcached and APC. In the setter, where the programmer can pick one of these engines, you make sure that he's not adding something your class can't work with.

Therefore we create an interface, which is pretty much just a fancy way of specifying which methods a class should have. Then all caching engines implement that interface.

// An interface that cache supported cache classes should implement
interface CacheEngine
{
    public function getValue($key);
    public function setValue($key, $value);
}

PHP:

In your main caching class, in the setter, you type hint $engine, and make sure that the class implements said interface. By doing so, you know that $cacheEngine has a specific set of methods, which you can reliably call at any time.

// Main caching class which supports multiple caching engines.
class Cache
{
    protected $cacheEngine = null;

    public function setCacheEngine(CacheEngine $engine)
    {
        $this->cacheEngine = $engine;
    }

    public function set($key, $value)
    {
        $this->cacheEngine->setValue($key, $value);
    }

    // ...
}


// Random caching classes
class MemcachedEngine implements CacheEngine
{
     // ...
}

class APCEngine implements CacheEngine
{
    // ...
}

// Example class that doesn't implement CacheEngine
class RandomClass
{
    // ...
}

PHP:

Now you do something like this:

$cache = new Cache();
$cache->setCacheEngine(new MemcachedEngine());
// or...
$cache->setCacheEngine(new APCEngine());
// but...
$cache->setCacheEngine(new RandomClass());
// ... fails, because RandomClass doesn't implements the interface.

PHP:

... this way you're always sure that $cacheEngine is what you expect it to be (an instance of a class that implements "CacheEngine"), and your class can handle it.

Don't over-think this, though. Is most cases you don't need getters and setters. I only use them to prevent errors before they happen (and especially where they can happen).

If you have a "User" class, and you want to change the user name, don't use a setter or getter. Just do:

$user = new User();
$user->name = 'Nico';

PHP:

In short, only use getters and setters where they make sense. Wildly adding them to support all properties doesn't make sense, and wastes CPU time.

 

Hmm, to bad you had to mention Interfaces as I am stranger to that concept ( I guess no surprises, considering I'm confused about getters/setters) Anyway, your example was very solid, and helpful, it may have given me so (unintended) understanding of interfaces along the way.

Thanks. I'll surely read it once more, in the future.