We’ve all seen it: we’re working along, and we come across code that just has a feel to it. It’s like déjà vu. You’ve seen this code before. You open another file – sure enough, there it is. The same code. Almost line for line.
In large code bases, it’s likely that there are dozens if not hundreds of similar behaviors that have to be completed more than once. And as code grows, is worked on by multiple developers, or just for the sake of speed, the same code gets copied or rewritten over and over again in different places.
Last week I finished up the first section of The Object Oriented PHP Masterclass. The class was great, and I learned about as much from my students as they learned from me. One of the most common questions I got from my students was “how do I make decisions about how to design my object oriented applications?” This question got me thinking about object oriented design.
The syntax of object oriented PHP is relatively straightforward…
In the second live session of my object oriented design class, The Object Oriented PHP Masterclass, I show my students domain modeling, both with slides and with a live coding demonstration.
In my demonstration, I show them how I break the single model they’ve been using into three component parts: a value object, a data layer object (usually that talks to the database), and a gateway object that stands between the other two.
In PHP (as well as many other object oriented languages), exceptions are simply objects, which can be extended and reused. PHP makes them special in the sense that only exceptions that inherit from the base class Exception are throwable by the interpreter (you cannot throw any generic object you create).
Most developers are therefore aware of the ability to extend exceptions, thus giving them unique, typehintable values that can be identified, caught and handled.
When I released Do This, Not That: Object Oriented PHP, I also included a free bonus of “Programmer in Command: What Aviation Teaches Software Developers”. This manifesto contains several suggestions that I learned over time as the best software development practices. I offered it until January 1st, 2013, and since that’s coming up on us very quickly, I wanted to offer a last chance to get it along with Do This, Not That: Object Oriented PHP.
Do This, Not That: Object Oriented PHP is aimed at developers who know the basics of object oriented development and want to learn the best practices as applied to PHP. Rather than teaching the basics of object oriented PHP, it shows you how combine the mechanics of object oriented PHP with the tried and true computer science best practices in a concrete way. And since PHP has a number of features not seen in other languages, it answers some of the most important questions about some of the PHP-specific features you’ll encounter.
The long wait is over! Do This, Not That: Object Oriented PHP is now available!