Stuffing a lot of functionality into your business objects to handle interaction with other objects can get ugly fast, especially if you are dealing with complex relationships and logic.
The first step beyond that kind of architecture is typically implementing service classes to facilitate the interaction between your objects.
Consider the following:
<?php
/**
* Class UserBasedServiceAbstract
* Base class for our user based services. All services must be instantiated
* with a valid user
*/
abstract class UserBasedServiceAbstract
{
protected $user;
/**
* UserBasedServiceAbstract constructor.
* @param User $user
* @throws Exception
*/
public function __construct(User $user)
{
if($user->isNew())
{
throw new Exception('User must be persisted before doing anything useful with it');
}
$this->user = $user;
}
/**
* @param $message
*/
protected function logAction($message)
{
$formattedMessage = (is_array($message)) ? json_encode($message):$message;
echo 'User action for '.$this->user->getUsername().': '.$formattedMessage;
}
}
class GroupService extends UserBasedServiceAbstract
{
/**
* Get a list of groups that the current user belongs to
* @return array
*/
public function getGroupList()
{
// We always have a reference to our user
$userId = $this->user->getId();
$this->logAction('Getting group list');
//Fetch groups for user
$groupList = [];
return $groupList;
}
/**
* Update the specified group if the current user has permission to do so
* @param Group $group
* @param array $params
* @throws Exception
*/
public function updateGroup(Group $group, array $params)
{
if(!$this->_userCanUpdateGroup())
{
throw new Exception('User does not have permission to update this group');
}
$this->logAction('Updating group');
//update group
}
/**
* Delete the specified group if the current user has permission to do so
* @param Group $group
* @throws Exception
*/
public function deleteGroup(Group $group)
{
if(!$this->_userCanDeleteGroup($group))
{
throw new Exception('User does not have permission to delete this group');
}
$this->logAction('Deleting group');
//delete group
}
/**
* Determine whether or not the current user can delete the specified group
* @param Group $group
* @return bool
* @throws Exception
*/
private function _userCanDeleteGroup(Group $group)
{
//Maybe there is some logic we need to check on the group before we go further
if(!$group->isDeletable())
{
throw new Exception('This group cannot be deleted');
}
// Implement some user-specific logic
return ($this->user->hasPermission('group_admin') && $this->user->getKarma()>100);
}
/**
* Determine whether or not the current user can update the specified group
* @return bool
*/
private function _userCanUpdateGroup()
{
// Implement some user-specific logic
return ($this->user->hasPermission('group_moderator') && $this->user->getKarma()>50);
}
}
You create an abstract class with the common functions you need, and to verify and hold a reference to your user. All of your services that need to be based around a user instance extend this class and facilitate interaction between the user object and the related objects. All of your logic around permissions goes into these service classes. This is a lot more maintainable than stuffing all of that into the business objects.
This approach can take you far. OO astronauts may tell you to go look at design patterns like the Mediator pattern for this kind of thing, and that can definitely work well, but there is always a trade off between complexity and ease of use. For most CRUD heavy applications, I find this service based approach to be the sweet spot.