Page 1 of 1

Best practice - interceptors

Posted: Mon Feb 18, 2008 10:00 am
by daveUK
Hi,

I'm pretty new to PHP5 OOP and was wondering if someone could advise me on what it the best practice when it comes to using Interceptors.

I have the following simple class, which gets/sets age & name. Is it best to use interceptors? Does anyone use them? I understand that phpDoc has problems documenting them as does intellisense in zendStudio.

Am I best exposing the getAge & setAge classes as public as well as using interceptors?

Thanks

Dave

---

Code: Select all

 
<?
 
Class Person {
 
private $_name;
private $_age;
 
function __get($property) {
$method = "get{$property}";
if (method_exists($this, $method)) {
return $this->$method();
}
}
 
function __set($property, $value) {
$method = "set{$property}";
if (method_exists($this, $method)) {
return $this->$method($value);
}
}
 
private function getName() {
return $this->_name;
}
 
private function setName($name) {
$this->_name = $name;
}
 
public function getAge() {
return $this->_age;
}
 
public function setAge($age) {
$this->_age = strtoupper($age);
}
}
 
$p = new Person();
$p->Name = "DaveUK";
$p->age = "25";
 
$p->setAge(($p->getAge() + 10)); // age = 35
$p->age += 10; // using interceptor // age = 45
print "age:". $p->age;
 
?>
 

Re: Best practice - interceptors

Posted: Mon Feb 18, 2008 10:49 am
by Sekka
Personally, I see no problem in using them as it gives a better API to the developer using the class. Instead of having to call a method to alter each property, they can alter the properties 'directly' and get exceptions when errors occur.

I learnt how to do this from an advanced PHP book [link] that said it was a good practice for developing decent APIs so I would say you are safe.

I use this method too if that's any comfort.

Re: Best practice - interceptors

Posted: Mon Feb 18, 2008 12:30 pm
by Christopher
It seems like a lot of code to just set the values of properties. Honestly, for the code you showed, you could just make the properties public. You don't do any sort of checks in your setters. The whole point of setters is of you want to somehow limit or filter how properties are set (e.g. limit length or range, transform values, make values write-once or read-only).

I also think creating two interfaces to do the same thing in a class is not the best design decision.

Re: Best practice - interceptors

Posted: Tue Feb 19, 2008 3:50 am
by daveUK
Hi arborint,

I agree with you, in this example exposing them as just public properties would be easier. However, I was trying to understand what is the best way of doing this when validation is implemented against properties. Sorry, I should have included this. It seems that there are two different camps:

1. Keep it simple and expose an consistent interface via methods, such as setAge, getAge - which will auto document well
2. Use interceptors, which providers a nicer, perhaps more usable, interface but has the downside of poor documentation

I just want to make sure that when I start coding a project I'm doing it a standard way, which others can follow and use.

Thanks

Dave