I speak a lot on design patterns. This year, I’ve given nearly a dozen talks on design patterns, relating to my book, Practical Design Patterns in PHP. One of the questions I get the most often about design patterns is, “how do I pick a design pattern to use in my project?”
My answer is always the same: you don’t.
There’s a lot going around right now about Facades. Laravel introduced the concept, or at least the term, to the PHP community in their framework. Given the popularity of the term, it’s worthwhile to define what a Facade is, and what a Facade is not.
The definition of a Facade
Chances are that any developer out there who has been involved in object oriented applications very long has run across the cardinal sin of object inheritance. I know I’ve committed this sin, and you probably have too. The sin of which I speak is a grave one, and it violates several well known and established principles of object oriented application development.
What is this sin of which I speak? It is none other than the addition of new public methods to an object that extends or implements abstract class or application interface, in violation of both the Liskov Substitution Principle and the Dependency Inversion Principle.
There’s an old quote: those who can, do and those who can’t, teach. This quote is humorous, but it’s definitely a misnomer about the challenge of teaching, especially in teaching technical subjects.
Last spring, I offered The Object Oriented PHP Masterclass for the first time. This class led students through hands-on development of their object oriented skills. I learned many things, including how challenging teaching is in many cases.
You’ve probably heard of the acronym SOLID by now, which is an object oriented programming paradigm consisting of five basic (but interrelated principles) of object oriented development.
And you’ve probably heard once or twice that the D in SOLID stands for Dependency Injection. Actually, if you’re lucky you’ve also heard what it really stands for, which is the Dependency Inversion Principle. But, in PHP, this is often conflated with dependency injection.
Lots of developers understand that object oriented code offers advantages over procedural programming. And so, they begin working on creating objects in their own projects, and eventually feel pretty good about what they’ve done. After all, if they’re using objects, their code must be object oriented, right?
Well, not exactly. They quickly find out just how limited their code is when they try to implement the concepts of object oriented programming, like reuse and extensibility. And they quickly find that their code is really procedural code wrapped up in classes, not the grand object oriented application they thought it was.