I have a long-standing client who has a complex piece of software that I developed for them some time ago. From time to time they approach me and ask me to make improvements to the software, which I am almost always happy to perform. And like any good client they want an understanding of the cost before they move forward, largely to ensure that the cost-benefit analysis makes sense. And so, they ask for an estimate.
I’ve written on estimates in the past. I don’t like them, largely because they can tend to box you into a particular position that may or may not be correct.
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.