PHP programming forum. Ask questions or help people concerning PHP code. Don't understand a function? Need help implementing a class? Don't understand a class? Here is where to ask. Remember to do your homework!
By the way - the thinking behind passing the developer to the item and not the other way round was just logical - to keep the item methods within the item class (create, delete, update etc)
No other reason
John Cartwright wrote:I think it should be the other way around, and you pass the item object to the developer object to be created, i.e.
$developer = new Developer();
$developer->createItem(new Item());
Reguardless, you can check the instance of the object using "instanceof"
By the way - the thinking behind passing the developer to the item and not the other way round was just logical - to keep the item methods within the item class (create, delete, update etc)
The item object should have no responsibility in knowing who is using itself. It is the responsibility of the developer or user class to determine whether they have access to using items.
Now, you can still keep all your methods in the item class, but the developer class should support some sort of composition to add items. I've added an example below, although I did use a fluent intertace to improve it's usability.
John Cartwright wrote:
The item object should have no responsibility in knowing who is using itself. It is the responsibility of the developer or user class to determine whether they have access to using items.
Now, you can still keep all your methods in the item class, but the developer class should support some sort of composition to add items. I've added an example below, although I did use a fluent intertace to improve it's usability.
$developer = new Developer();
$user = new User();
$developer->parent::item(new Item())->create();
//or
$developer->parent::item(new Item())->update();
//etc
$user->item(new Item())->view();
class Developer extends User
{
}
class User
{
protected $_item;
function item(Item $item)
{
$this->_item = $item;
return $this->_item;
}
}
class Item
{
public function __construct() {}
public function create()
{
//do create item stuff
return $this;
}
}
Is that right?
But then surely that means that a basic User could also access create? delete? etc
A basic user should not be able to access these methods
Last edited by paraleadogg on Wed Mar 25, 2009 12:53 pm, edited 1 time in total.
//no access controls
class DeveloperItem extends Item { }
//access controls
class UserItem extends Item {
public function create() {
throw new Exception('UserItem cannot implement Item::create()');
}
public function update() {
throw new Exception('UserItem cannot implement Item::update()');
}
}
and maybe even a factory to return the appropriate child item depending on users role. The point is that the Item class should not be concerned about it's own implementation.
But like I say this may not be ideal for your situation.
Basically a developer inherits from User. So if i wanted developers and basic users to have access to different methods within the Item class I could do this
$developer = new Developer();
$user = new User();
$developer->parent::item(new Item())->create();
$developer->parent::item(new Item())->update();
$user->item(new Item())->view();
class Developer extends User
{
}
class User
{
protected $_item;
function item(Item $item)
{
$this->_item = $item;
return $this->_item;
}
}
class Item
{
public function __construct() {}
public function create()
{
//do create item stuff
return $this;
}
}
But then a basic user would also have access to methods they shouldnt have (like create, update etc) wouldnt they?