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.
Many people wonder how they can improve the overall readability and cleanliness of their code. It seems impossible to understand exactly how to rewrite code in such a way that makes it clean, easy to understand and simple to work with. But clean code is about a few simple principles, one of which is reducing overall code complexity through a series of simple steps.
I’ve been working on a new book on clean code for the last few months. While I know that I’ll never answer all the considerations regarding clean code, I believe that I can make an impact in showing people how to measure their code’s cleanliness, and know exactly what they need to fix. One metric that I’ve been focusing on for the last few weeks is code complexity.
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.