Laravel Internals: Proxy pattern with the ForwardsCalls trait
Tags: php, laravel, softwaredevelopment, softwareengineering
Published: 2021-12-16 12:00:56

---
title: Laravel Internals: Proxy pattern with the ForwardsCalls trait
published: true
date: 2021-11-29 13:02:44 UTC
tags: php,laravel,softwaredevelopment,softwareengineering
canonical_url: 
---

![](https://cdn-images-1.medium.com/max/1024/0*HfV93uEQe6TR2z2O)
_Photo by Quino Al on Unsplash_

Sometimes it’s good to put PHP’s magic methods to use. One such magic method is \_\_call which allows for virtual methods to be called on an object. This also helps with the [Proxy pattern](https://refactoring.guru/design-patterns/proxy) where one object might accept another object via the first class’ constructor to then proxy all subsequent missing method calls to the second object.

One of Laravel’s internal traits actually makes this process a lot simpler. We can implement by just creating a class with the ForwardsCalls trait. Then we add our own \_\_call function to the class with will pass the object we’re proxying, the name and the parameters to the forwardCallTo.

{% gist https://gist.github.com/peterfox/29ece7fa69fbfe19640e88d3146572d4 %}

As you can see this example works nicely to allow use to forward and calls to the object. You might wonder though, why can’t we just use the call\_user\_func function?

Well you could but the problem with this comes when you then make a mistake calling a method that does not exist on the target object. See below:

{% gist https://gist.github.com/peterfox/6819b7dd903fd5e9ab3ce3f029fe1cec %}

As you can see the message is a bit vague and non descript. We get a TypeError instead of a clearly defined exception. We could just apply a call directly to the object, maybe that would work better?

{% gist https://gist.github.com/peterfox/97bd63a1e75b78401ef4f35c0d0d8473 %}

This is ok but we’re getting a PHP error instead of an exception, as well as only getting a message about the Target class instead of the Proxy class. That still requires us to remember that the Proxy class is being used.

Now let's see what happens when we use the ForwardsCalls trait instead.

{% gist https://gist.github.com/peterfox/fc8e5f8ca40c7fc08a9c33b391fbb42f %}

That’s right we now get a far nicer BadMethodCallException which tells us the Proxy class that failed with an undefined method so we don’t have to look into the stack trace to know which class does not have that method.

### Conclusion

Often it’s the case Laravel has a hidden treasure or two like this within it’s code. While the impact of this one is minimal, it’s always something to keep in mind as part of the developer experience. If you had a message like the one provided from call\_user\_func upon a missing method call, how would you debug it when it’s occuring in a production environment? How obvious would it be to track down the cause of the error? Little traits like ForwardsCalls can save a lot of time and headaches for you in the future.

<hr>

I’m Peter Fox, a software developer in the UK who works with Laravel among other things. Thank you for reading my article, I’ve got several more on both medium and dev.to. If you want to know more about me, head over to [https://www.peterfox.me](https://www.peterfox.me/). I’m also now also [Sponsorable on GitHub](https://github.com/sponsors/peterfox?frequency=one-time&sponsor=peterfox). If you’d like to encourage me to write more articles like this please do consider dropping a small one off donation.