Implementing the Factory pattern with Laravel 5.4 and Eloquent

Ok, so this particular problem took me a while to solve, but it turns out to be a useful technique, at least in my case, so I’m reproducing it here in the hopes that if you’re searching around on the internet looking for an answer, it’ll save you a little bit of time.

First, let’s describe the problem.

Let’s say you have a basic Laravel class something like:

namespace App;

use Illuminate\Database\Eloquent\Model;
use Illuminate\Database\Eloquent\Collection;
use Illuminate\Support\Facades\DB;

class Aspect extends Model{
    public function display(){ ... }
}

And you have a bunch of other classes that extend your base class, including, possibly, classes that do not yet exist.

class SpecialAspect extends Aspect{
    public function display() { .... but with something different! }
}

class StupidAspect extends Aspect {
    public function display() {  ... and something else is different! }
}

Now, all of these classes will share the same underlying table, which includes a field which specifies what type of Aspect each record represents.

And what you want to do is to continue using Eloquent ORM to work with collections of aspects, such that belongsToMany() and the like will give you back a Collection object containing a bunch of Aspects, all cast into the correct sub-classes (e.g., [Aspect, Aspect, SpecialAspect, Aspect, StupidAspect]).

So you try it out, and you find everything is getting returned as the base class [Aspect, Aspect, Aspect, Aspect, Aspect].

Laravel thinks that you only want instances of the base class, but you don’t; you want the object with overridden methods to load correctly so you can work with them normally.

This is the classic use-case for the Factory pattern.

So how do you do it?

What you do is create a Custom Collection object to override the normal Collection method that your object uses.  In the Custom Collection, you iterate through the objects available, figure out what type the are supposed to be, and then create new objects of those types.  Then you essentially load the data into them manually, build them into an array, and replace the $items in the Custom Collection with your new array of objects.

So first, modify your base class to implement a custom collection method.  While you’re at it, make a manual_load() method as well; remember, the newCollection method is going to override the normal Collection method all the time, so if you don’t load your objects up manually, you’re going to get yourself into a situation with an infinite loop, until you run out of memory:

namespace App;

use Illuminate\Database\Eloquent\Model;
use Illuminate\Database\Eloquent\Collection;
use Illuminate\Support\Facades\DB;

class Aspect extends Model{

    public function display(){ ... }
    
    public function newCollection(array $models = []){
        return new AspectCollection($models);
    }
    
    public function manual_load(){
        // use the DB::select method to pull your data out of the underlying table
        // and add it to the respective properties on $this
    }

}

So far, so good.

Now, you’re going to want to build your custom Collection object:

class AspectCollection extends \Illuminate\Database\Eloquent\Collection {
    public function __construct($items){
        parent::__construct($items);
        $this->recastAll();
    }      
    
    private function recastAll(){
        $new_collection_array = array();
        foreach ($this->items as $k => $m){
            $new_object = AspectFactory::make($m->id);
            $new_collection_array[$k] = $new_object;
        }
        $this->items = $new_collection_array;
    }
}

You’ll notice from that class, there is yet a third class that we’re going to need, an AspectFactory class that decides what kind of object you’re going to create for each individual element, so we’ll create that too:

class AspectFactory{
    public static function make($aspect_id){

        $new_classname = 'App\DefaultAspect'; // <--- if we don't have a custom type, we'll use this as our default.

        $new_type_name = DB::select('SELECT aspect_name FROM { ... whatever query will give you the name you need} ); 
        $mutated_aspect_type = $new_type_name[0]->aspect_name;
        $custom_classname = 'App\\' . $mutated_aspect_type . 'Aspect'; // This string is the name of the class we're going to test for.

        if ( class_exists( $custom_classname ) ){
            // The custom class exists, so override our default.
            $new_classname = $custom_classname;
        }

        $finder = new $new_classname();  // Here, we create the new class.
        $finder->id = $aspect_id;        // Assign the ID to the new object
        $finder->manual_load();          // Call that manual_load() method we wrote for our base class.
        return $finder;                  // Send our custom class back to our Custom Collection.    
    }
}

So now, if you have a relationship that looks like:

App\Subject->belongsToMany(‘App\Aspect’);

Then you can do Eloquent operations such as:

$s = new Subject::find(1);
foreach ($s->aspects as $a ){
     $a->display();
}

And the correctly overridden display() method will spit out whatever it is you’ve got it doing, because your Collection will look like:

[
   0 => Aspect, 
   1 => Aspect, 
   2  => SpecialAspect, 
   3  => Aspect, 
   4  => StupidAspect
]

Or whatever.

And there you have it.  Implementing the Factory pattern with Laravel (5.4).

 

UPDATE (1/3/2018) : Giulio Troccoli-Allard very helpfully got in touch (thanks!) with me to point out the recastAll() function in the collection class wasn’t preserving the keys of the items.  He included some code to provide the enhancement, and so I updated the relevant portion above.