| « The “D” Doesn’t Stand For Dependency Injection | A Super Productive Quarter At Mozilla » |
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.
But how can you know ahead of time what kind of code you have? Is there a set of tools you can use to determine if your code is truly object oriented, or is it just procedural code wrapped in classes? Let’s take a look at the hallmarks of truly object oriented code and find out.
The biggest indicator of truly object oriented code is whether or not it correctly splits responsibilities up between classes – a principle known as the single responsibility principle.
In object-wrapped procedural code (OWPC), many responsibilities will exist within the same objects. You’ll have database connections being made, queries being run, data being evaluated, and even possibly display functions being performed. But truly object oriented code will break these behaviors apart into their component parts, focusing on each one individually.
So, I just used a big word: polymorphism. But even though the word seems scary, it’s not: polymorphism is just a principle which means “one behavior, many forms.” For example, all SQL databases perform similar behaviors, but they have individual implementation details for connecting and passing messages around. A polymorphic database layer will implement a common behavior for all the databases, and obscure the specific implementation details for each unique database type.
What this leads to is easy reuse of objects throughout your code. For example, you can switch easily from MySQL to SQLite if you have a true object oriented application that has a truly polymorphic database layer.
A truly object oriented application will correctly apply dependency injection. Often in OWPC applications, objects are instantiated directly, either inside classes or inside procedural files. But an application designed to be object oriented will utilize dependency injection as a means of allowing for inversion of control.
This is done in PHP usually in one of two ways: first, there can be a layer responsible for instantiating objects (usually a controller). Or, there can be a dependency injection container that holds (or creates) the objects needed in the application. Both approaches are reasonable, and both are widely used.
The truth is that designing applications to be object oriented is challenging, frustrating, and extremely worthwhile. Conquering the challenges results in reusable, segmented, small bits of code that are easy to maintain, simple to understand and incredibly powerful when used correctly.
Brandon Savage is the author of Mastering Object Oriented PHP and Practical Design Patterns in PHP
Posted on 7/15/2013 at 7:00 am
Tjorriemorrie (@Tjorriemorrie) wrote at 7/17/2013 2:51 am:
I’ve been thinking this for years, so glad someone blogged about it; not it’s bookmarked for reference. Do you think: testing can also help you develop better OOP (as part of this topic)? I’ve been considering that if people wrote tests, they would also understand why they’re code doesn’t follow the OOP principles.
Tony Marston wrote at 7/17/2013 4:37 am:
I disagree. Object Oriented Programming *IS* nothing more than programming which is oriented around objects, but with the proviso that it takes advantage of Encapsulation, Polymorphism, and Inheritance to increase code reuse and decrease code maintenance.
There is no such thing as a single style which is “right”, thus making all other styles automatically “wrong”. If you are free to choose whatever style you want, then you must allow others the same freedom and not start to dictate what is right and what is wrong.
I particularly disagree that to be a “proper” OO programmer you must use dependency injection. DI is a possible solution to a particular problem – not the only solution, and perhaps not the best solution – so if I don’t have that particular problem in my code then I’m not going to waste my time implementing that solution. That’s what the YAGNI principle is all about.
| « The “D” Doesn’t Stand For Dependency Injection | A Super Productive Quarter At Mozilla » |