What object-oriented programming is NOT

I’ve made this argument several times, but object-oriented programming is MORE (much more) than knowing how to write a class. It’s a “paradigm” (as WikiPedia calls it) or a “model” (that’s Tech Target’s word). I call it an “approach”… but it’s an approach to application-building.

OOP is not about how you write your code… it’s about how you build your applications. That may not make sense, at first… but it is an important distinction. So, let’s look at some code and see if we can make this clear.

So, the first thing object-oriented programming is not is…

Object-Oriented Programming Is Not Writing a Class

You use classes, but that’s not what it IS. A lot of times what I see developers do is take a set of functions like this:

<?php
function my_func_one() {
    // do stuff
}
function my_func_two() {
    // do stuff
}

And, just do this with it:

<?php
class MyClass {
    function my_func_one() {
        // do stuff
    }
    
    function my_func_two() {
        // do stuff
    }
}

That’s not object-oriented programming… that’s namespacing. Which is fine, but you’d be better off just using actual namespaces like this:

<?php
namespace App\Functions;
function my_func_one() {
    // do stuff
}
function my_func_two() {
    // do stuff
}
// Note: prior to PHP 5.6 this wouldn't work because importing function and
// constant names wasn't supported. 5.6+ DOES support this.

It’s simpler syntax, it’s easier to update your existing procedural code and you’d being using the “right tool for the right job” in my opinion.

Object-Oriented Programming Is NOT Static

Another one I see is heavy use of the “static” keyword. So something like this:

<?php
class MyClass {
    public static function my_func_one() {
        // do stuff
    }
    public static function my_func_two() {
        // do stuff
    }
}
MyClass::my_func_one();
MyClass::my_func_two();

This is really the same mistake as before, just more fancy-looking. The reason you’d do this is to put your functions into a class and be able to call them in the procedural way you’re used to… but not have to “mess with all that instantiating nonsense”. This, again, is really just namespacing. (There are proper uses of “static” in OOP, but they’re fairly rare. So, if all or most of your class methods are static… that’s not object-oriented programming.)

Object-Oriented Programming Is NOT MVC

This will ruffle a few feathers probably, but OOP and MVC are, in fact, two different things. OOP is an “approach” (model, paradigm) to application-building. MVC is one, of many, application design patterns that employ OOP principles. So, you can “do OOP” without MVC.

I bring this up because MVC’s popularity (for good reason) tends to make people think that’s all there is. “If I’m gonna OOP, I gotta MVC.” But, there are plenty of other patterns out there… some of which I personally prefer to MVC.

That’s why in my object-oriented programming course, I show you MVC, but I also show you another design pattern… one I personally like better. To challenge you to think about it different ways and develop what works for you… not just follow what everyone else is doing.

That and a lot of the frameworks that employ MVC principles actually use a distorted form of it… but that’s a topic for another time.

What Object-Oriented Programming IS

I’ll re-iterate… it’s an entire “re-thinking” of how you build your applications. Procedural coding tends to focus on process over data. We think of what we need to DO first. We need to process this form data or edit this blog post. And, those processes tend to be what drives our application design decisions.

OOP is different. It focuses on the data first. Instead of breaking your applications down into processes, you break into down into objects. And, objects here is used in the general sense… a phone is an object, a remote is an object… these things are literal objects in the real world.

So, we build our applications in the same way we view the world in real life. We break a CMS down by “post”, “category”, “tag”, “author”, “comment”… and we think about our data model FIRST. Then, we write the code to create, read, update and delete.

It’s Not Your Fault

Now, I know you might feel like I’m ragging on you if you’ve done any of this stuff. I’m not. I did all the same stuff. Probably anyone who’s made the switch from procedural to object-oriented programming did this same stuff.

I think most coders’ minds are naturally oriented to think in processes. So, breaking out of that is difficult. But, ultimately, for large, complex applications OOP is a better way to build. It’s easier to think about your application mentally in this way. Your code is often more organized. And, it’s more in line with how your end-user sees your application.

If you’d like to dive into all this more, then check out my object-oriented programming course. I’ll clear up all the confusion you might have surrounding OOP and show you how to build professional PHP applications using object-oriented programming.