Developer Blog

  • Blog
  • /
  • Thoughts on using Facades, or your users are not stupid
By Dracony on 13 January 2014

There is (and has been for a long time) some discussion about Laravels’ approach to hiding the composition of core components behind a facade. Now, for those who don’t know yet, in OOP world a facade is an object that simplifies working with a complex system buy providing a simple interface. Before talking about this let’s take a better look about how they are implemented inside that framework:

Laravel takes the concept in a bit of a different direction and instead of providing a single facade for the whole system it creates multiple mini-facades for every part of the system. Their official docs say that Facades provide a “static” interface to classes that are available in the application’s IoC container. I would say that they need to update it to say that this is how their facades work, not how they are generally thought of. There has been a lot of discussion on whether their static approach (and I don’t know why they put brackets around the word “static” since it is indeed static) is beneficial or harmful, so I won’t talk about that either, there is a bigger question to discuss here.

Should developers dumb down their frameworks?

Every developer wants his product to be used, and does as much as possible to broaden his target audience. One of the best things he can do is providing a nice learning curve that would let people gradually get more and more acquainted with his product. Unfortunately this may sometimes lead to rather bad chices that might hurt in the long run. The success of rather complex frameworks like Symfony2 should have taught us that keeping things complex but correct isn’t necessary a hurtful decisions. I’ve known a lot of people switching back an fourth between “easy” frameworks like Laravel and Yii, but I’ve seen only a couple leave Symfony2 after they’ve got to grips with it. Even now a lot of causes for choosing Laravel on reddit go along the lines of “Symfony was too complex”. Now myself I don’t think Symfony is perfect, but I think it makes a good example of the point I’m trying to get across.

Dumbing the framework down and hiding it behind a facade is in my opion a bad idea, since when the developer reaches the level of understnding required to get IoC an dependency injection he will find himself refactoring a huge pile of working code. The framework shouldn’t ease things down, on the contrary it should enforce best practices, and even though it will make the user hate it for the first week, he will fall in love with it after a month.

Good documentation better than simplification

So how should a framework ensure a nice learning curve while requiring high cde standarts? The answer lies in providing a good documentation. People dump harder frameworks because they say they can get same results in less time using a different one. This is not a code issue, but a documentation problem that should be solved by providing extensive tutorials and practical examples.

What if you have great docs but some users are too lazy to read those? Well, you can’t win them all, can you.

comments powered by Disqus