Andre Liem

Laravel + Statics + Facade = Confusion for Newcomers

I recently found myself replying to a question on Quora Why-do-Laravel-developers-used-to-ignore-OOP-techniques-and-even-MVC “. At first it sounds like a pretty ignorant question, Laravel is MVC to its core, just like the many MVC frameworks out there. MVC is part of OOP, so what is he talking about? I already had a hunch that there was one thing that he was seeing in the community because I faced it when I first picked up Laravel. It can really be summed up by Facade + Static envy.When I first picked up Laravel, I remember reading through the docs and being impressed at how well it was documented and easy to pickup. It’s definitely up there with one of the easiest frameworks I’ve ever used before. Especially in comparison to the modern day Javascript front end framework which should require a basic npm install but turns into a big hot mess of dependency versioning hell. Laravel comes very well equipped, and there isn’t much changing in terms of what it depends on so you typically don’t have to do a lot when you go composer install.

So where do the problems come from? I personally believe the one thing that can send a newcomer down the path of really bad code is a misunderstanding of the Facade pattern. Lets look at this straight forward example from the docs.

Anyone with any software development experience will know what’s going on here. Fetch all the flights from some data store, iterate through and output the name attribute.

A newcomer might also be amazed it how little code was needed to retrieve the flights, one static call to :all and you get the records, no instantiation or crazy query logic.

An experienced developer from another framework or language would be thinking why are we using statics? They would read the docs, and find this explanation:

Facades provide a “static” interface to classes that are available in the application’s service container. Laravel ships with many facades which provide access to almost all of Laravel’s features. Laravel facades serve as “static proxies” to underlying classes in the service container, providing the benefit of a terse, expressive syntax while maintaining more testability and flexibility than traditional static methods.

With this they would either think that’s great, nice convenient pattern to keep my code clean. Or they might reject this idea and post about it, it’s a good post to read through as he’s done his research.

The practical problem for beginners as I see it is not the question of what is a better “design” decision, Facades or forcing instantiation the old way (hopefully through some form of constructor injection or factory method). It’s that you want your code to be that easy as well, so to mimic the look of those handy static calls you start to actually build static methods for all objects. It’s a simple thing to do, you need a more specific function to get data from a table, so you create something like getAllBanned. But to make it Laravel like, you create a static function so you can go User::getAllBanned.

So now you have real static functions taking over your objects and then the original question posed on Quora makes sense. If all your functions are static then why even use an Object or call this OOP. In effect you would just be using an object as a form of namespacing and that’s it.

Really the solution to this problem is to ensure any newcomer to Laravel reads the docs and understands the Facade pattern. I believe it’s very important for Laravel because it’s catering to a very large PHP community with a lot of developers who probably use MVC but probably don’t know about the Gang of Four or really care too much about design.

 

 

 

 

 

Leave a Reply

Your email address will not be published. Required fields are marked *