Close

object-oriented programming

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.

December 22, 2017

Inheritance In a PHP Class and Object-Oriented Programming

Let’s talk about inheritance in PHP. First, here’s how you do it:

<?php
class Daddy {
public function my_method() {
echo “I’m the parent”;
}
}

class Son extends Daddy {

}

$child = new Son;
$child->my_method(); // This outputs “I’m the parent” from the parent class

The child is the class DOING the extending. The parent is the class BEING extended. And, the child inherits any public or protected properties and methods from the parent. This is why “Son” has no methods, but still outputs the results of my_method(). Because it inherited that method from Daddy.

But, private methods and properties are NOT inherited. So, this won’t work:

<?php
class Daddy {
public function my_method() {
echo “I’m the parent”;
}

private function you_cant_haz() {
echo “Only Daddy gets me!”;
}
}

class Son extends Daddy {

}

$child = new Son;
$child->you_cant_haz(); // This triggers a fatal error

You can also override inherited methods in the child. Like this:

<?php
class Daddy {
public $var = “Call me Daddy! “;

public function my_method() {
echo $this->var;
}

private function you_cant_haz() {
echo “Only Daddy gets me!”;
}
}

class Son extends Daddy {
public $var = “Uh, that’s creepy. No!”;

public function my_method() {
echo $this->var;
}
}

$parent = new Daddy;
$parent->my_method(); // This outputs “Call me Daddy!”

$child = new Son;
$child->my_method(); // This outputs “Uh, that’s creepy. No!”

One example use case for this is WordPress widgets. When creating a new widget, your individual widget class extends WP_Widget to access and override its default methods. WordPress then does the “magic” of putting your widget together simply by you overriding the WP_Widget methods in your class.

Another example is the example OOP application shell I show you how to build in my object-oriented programming course. I give you a primer on MVC, which is obviously super popular right now, but is only one among many design patterns. But, I also show you another pattern I learned a few years back that I personally like better… and it involves some strategic inheritance like this. You can learn more about and enroll in my object-oriented programming course here.

December 21, 2017

[Periscope] How to Learn Object-Oriented Programming in PHP

In this week’s WebDev Q&A, I answer questions on:

  • There is so much to learn and it’s changing all the time, how do I know where to focus and what to choose to pursue?
  • How do I learn object-oriented programming?
  • How can one tell if I am good enough?
  • I’ve learned HTML and CSS, how do I make the transition into learn PHP, MySQL and Javascript?
  • I’m learning how to work with databases, what all do I need to learn?

Watch below:

Links mentioned in the video:

 

If you get value from this video, please consider sharing it with another developer or group who could benefit from it.

October 21, 2015