1

I had a very long "Playlist" class; having functions that, among others, would handle the playlist cache, variables, and presets.

class Playlist{

    var $cache;
    var $variables;
    var $preset;

    function __construct(){
        $this->cache = populate_cache();
        $this->variables = $this->populate_variables();
        $this->preset = $this->populate_preset();
    }
    function populate_cache(){
    }
    function populate_variables(){
    }
    function populate_preset(){
    }
}

As it was becoming very difficult to read (lots of function for stuff related to cache, variables, presets), I started to split that into several classes (code is reduced here):

class Playlist{

    var $cache;
    var $variables;
    var $presets;

    function __construct(){
        $this->cache = new PlaylistCache($this);
        $this->variables = new PlaylistVariables($this);
        $this->presets = new PlaylistPreset($this);
    }
}

class PlaylistCache{
    var $playlist;
    function __construct(&$playlist){
        $this->playlist = $playlist;
    }
}

class PlaylistVariables{
    var $playlist;
    function __construct(&$playlist){
        $this->playlist = $playlist;
    }
}

class PlaylistPreset{
    var $playlist;
    function __construct(&$playlist){
        $this->playlist = $playlist;
    }
}

So the Playlist object is passed to every "subclass". If I well understood, this is called Dependency Injection. I'm not sure this is very smart since

  • It seems to me quite a weird way of coding.
  • It produces recursions in my code, eg. the playlist object is passed to the PlaylistCache class; but the PlaylistCache IS defined in the playlist object, which makes ... a nasty loop. If I print_r my Playlist object, i'll see RECURSION written in the code.

BUT I need to be able to access the whole Playlist object through every subclass, and that's the only way I found for the moment.

I already know about extending classes, but I don't want to extend my class here : cache, variables and presets are not a different kind of Playlist, they are "properties" that my Playlist needs to populate.

I dug a little and read about Abstract Classes, Traits, Interfaces, and i guess my solution is somewhere in that. But I can't find where and it's quite difficult for me to understand since it's really abstract and english is not my first language.

So : does anyone see what I mean and have suggestions ? Thanks !

Natalie Hedström
  • 2,607
  • 3
  • 25
  • 36
gordie
  • 1,637
  • 3
  • 21
  • 41
  • What you are doing is not dependency injection, just regular parent/child relationships. And the recursion is not a bad thing at all, it just illustrates the underlying mutual dependency. So all in all, not much wrong with your code right now apart from all the `&`'s in the constructors. – Niels Keurentjes Jan 15 '16 at 11:34
  • @NielsKeurentjes, it is by no means a *parent/child relationships*. It is a composition. – Alex Blex Jan 15 '16 at 11:43
  • And composition is one of (many) ways to express a functional parent/child relationship. DI on the other hand is not about hierarchical relationships but about the separation of concerns. The linked article about DI is bullshit, and written by a narcissistic idiot. – Niels Keurentjes Jan 15 '16 at 11:49

1 Answers1

0

Some of the comments are misleading. The "child" classes use Dependency Injection and not an Inheritance parent/child relationship. The playlist (parent) class does use composition, however.

The &'s in the constructors constitute 'passing by reference'. To pass by value, the class would need accessor methods. If you only ever want one instance of say... the current playlist, a singleton makes sense. Traits are a copy paste solution - the design for a singleton pattern could be housed in a trait, but the use of a singleton would not be.

Consider what the playlist* classes actually need from the Playlist and consider passing those values explicitly.

Community
  • 1
  • 1
Kyle Wiering
  • 444
  • 5
  • 15