Dependency Injections
When creating PHP classes, particulary when utilising Unit tests, its a good idea to use dependancy injections. This enables us to use a robust reliable class which is not hard coded to rely (depend) on certain factors.
If you were to use the Zend_Mail_Service in your class, it would work fine, but we would come across a couple of drawbacks.
The major problem being that we have no control over the object (Zend mail) – only the class can control this. Which is fine, until you need to re-use the class with a different mail service. We would end up having to alter the class code.
Here is an example of a hard coded dependancy:
<?php
class myClass {
protected $_mailService;
public function __construct() {
//lazily just use the Zend Mail object
$this->_mailService = new Zend_Mail_Service();
}
}
If we were to use dependancy injection on this class, we could set the object that the class relies from outside of it. Thus gaining control over the class itself. We could use a setter for this to work, and we can use a default if required. Below is an example of a setter based injection:
<?php
class myClass {
protected $_mailService;
public function __construct() {}
public function set_MailService($objMail) {
//store the object into the class
$this->_mailService = $objMail;
}
public function get_MailService() {
//if we have no object set
if (null === $this->_mailService)
//we use the default object - Zend
$this->_mailService = new Zend_Mail_Service();
}
}
}
So now, we can set the object that our class relies on, from outside the class. This makes the class more re-usable, and that, after all is the whole point of OOP. This is especially useful when you want to perform unit testing on the code, and you don’t particulary want the server emailing left-right and centre…
When creating PHP classes, particulary when utilising Unit tests, its a good idea to use dependancy injections. This enables us to use a robust reliable class which is not hard coded to rely (depend) on certain factors.
If you were to use the Zend_Mail_Service in your class, it would work fine, but we would come across a couple of drawbacks.
The major problem being that we have no control over the object (Zend mail) – only the class can control this. Which is fine, until you need to re-use the class with a different mail service. We would end up having to alter the class code.
Here is an example of a hard coded dependancy:
<?php
class myClass
{
protected $_mailService;
public function __construct() {
//lazily just use the Zend Mail object
$this->_mailService = new Zend_Mail_Service();
}
}
If we were to use dependancy injection on this class, we could set the object that the class relies from outside of it. Thus gaining control over the class itself. We could use a setter for this to work, and we can use a default if required. Below is an example of a setter based injection:
<?php
class myClass {
protected $_mailService;
public function __construct() {}
public function set_MailService($objMail) {
//store the object into the class
$this->_mailService = $objMail;
}
public function get_MailService() {
//if we have no object set
if (null === $this->_mailService)
//we use the default object - Zend
$this->_mailService = new Zend_Mail_Service();
}
}
}
So now, we can set the object that our class relies on, from outside the class. This makes the class more re-usable, and that, after all is the whole point of OOP. This is especially useful when you want to perform unit testing on the code, and you don’t particulary want the server emailing left-right and centre…