The biggest complaint people have about object-oriented design is where they put all the “glue code” that ties together a bunch of objects and makes them work well. For many, this place is the controller, but as I’ve covered before, most of this logic belongs in the model. In fact, the model should be where all business logic resides. And yet, it can still seem difficult to figure out precisely how to manage all of these behaviors in one place and still follow the best practices of object-oriented design and development.
But there is a way to accomplish this that won’t make you crazy. It’s accomplished by making use of “services” – bits of code that act as the “glue code” for all the different objects that have to operate.
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.