Aliasing utility class method in extended class Consider this setup:

class UtilityClass
{
    public function formatNumber($input) {
        return number_format($input, 0, '', ' ');
    }

    public function trimText($input) {
        return substr(trim($input), 0, 100);
    }

    // bunch of other methods
}

class SessionClass
{
    public $utils;
    private $permissions = array();

    function __construct() {
        $this-&gt;utils = new UtilityClass();
        $this-&gt;setPermissions();
    }

    public function getPermissions($type) {
        return $this-&gt;permissions[$type];
    }

    public function getSettings() {
        // do stuff
    }

    private function setPermissions() {
        // do stuff to set $this-&gt;permissions
    }

    // bunch of other methods
}

class BaseClass
{
    public $session;

    function __construct($session) {
        $this-&gt;session = $session;
    }

    // bunch of methods
}

class ExtendedClass extends BaseClass
{
    // bunch of methods
}

$session = new SessionClass();
$extClass = new ExtendedClass($session);


When I want to use the formatNumber method of UtilityClass in my ExtendedClass, I can do it from within ExtendedClass like so:

$this-&gt;session-&gt;utils-&gt;formatNumber('some input');


...because the $session object, containing the $utils object, was injected into the $extClass object. However, if I use the formatNumber method from UtilityClass very often in ExtendedClass, it means quite a lot of (long) calls like written above. I could shorten it by using 'traits', changing:

trait Utilities
{
    function formatNumber($input) {
        // do something and return
    }
}


...and:

class ExtendedClass extends BaseClass
{
    use Utilities;

   // bunch of methods
}


I could then do the same call like this:

$this-&gt;formatNumber('some input');


I could put use Utilities in BaseClass so all extended classes could use it. But I would have to put an extra use Utilities in SessionClass, because that needs it as well. So then I end up with a $session object and an $extClass object which both contain the methods from the Utilities trait, and one is injected into the other. That seems wrong.

Another solution is 'aliasing' the formatNumber method from the UtilityClass class. To that end, I could change BaseClass:

class BaseClass
{
    function __construct($session) {
        $this-&gt;session = $session;
    }

    function get($input) {
        return $this-&gt;session-&gt;utils-&gt;formatNumber($input);
    }

    // more methods
}


This also seems not quite right. Is there a better solution? What would give the best performance/least redundancy?

Could PHP 5.6 offer the best solution? Using namespaces: Aliasing/Importing

Using use you can now 'alias' a function like this:

// aliasing a function (PHP 5.6+)
use function My\Full\functionName as func;
I'm not a fan of the UtilityClass. Here's some examples:


It breaks the single responsibility principle as it is not focused on solving a specific problem.
UtilityClass:trimText() conveys too little context about what it does, and the result of calling the method is unexpected. UtilityClass::trimText() would better suit the problem with signature like UtilityClass:shortenTextTo($text, $length);
UtilityClass::formatNumber() is not specific enough to explain clearly what it does. How does it format the number?


UtilityClass:trimText() seems like a good fit for a static helper. The problem you are trying to solve looks visual, and you should try to convey that. Look at the following:

class Text {
    public static function shortenTo($text, $length) {
        return substr(trim($text), 0, $length);
    }
}

// Html
&lt;article&gt;
    &lt;h1&gt;My awesome blogpost!&lt;/h1&gt;
    &lt;p&gt;&lt;?= Text::shortenTo($text, 100); ?&gt;&lt;/p&gt;
&lt;/article&gt;


Now you have a utility for shortening a text to the wanted length.



Your session class also deals with the wrong problem. A session class would represent a Session (i.e a value object) or handle actual session management, but it wouldn't set permissions. An Authenticator class could use a SessionManager to assign specific permissions TO a session, but Sessions should have no understanding of what permissions are. 

Hope that gives you something to work on. Your code is not horrible, but it seems to not focus on solving the right problems in the right places. The point of object-orientation is to represent code in realistic, understandable models, and your code does not do that at the moment. Focus on what a Session represents. What actions should you be able to do with a Session object?