Writing Objects doesnt' make it OOP

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.

Object oriented code splits responsibilities between classes.

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.

Object oriented code is polymorphic.

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 behaviour, 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 behaviour 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.

Object oriented applications apply dependency injection.

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.

Object oriented design is challenging, but worthwhile.

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.