The standards for WordPress development are slowly moving from turns of procedural code that lack proper abstraction to more SOLID and object-oriented code.
That’s a step in the right direction, but let’s not forget two important things that often get left out of these discussions: putting code in a class does not make it “object-oriented,” and object-oriented PHP is not, by definition better.
Today, we will discuss what what an object is and what its role is. Then we can discuss what we mean by “true object-oriented programming” and whether it really matters if your code is “true OOP” or not.
Arrays vs Objects
PHP has two compounds (also known as composite) data types: objects and arrays. Compound data types require composition — the process of combining other data types into one “unit.” In purely object-oriented languages, we have to compose data types that in PHP are available to us as primitive types.
When explaining objects and object-oriented programming, I think it is really useful to start by talking about arrays, which are not objects. The fundamental difference between a PHP array and an object is that we can’t change the rules of an array. PHP the language defines what we can and can’t do with an array and there is no way for your PHP program to change that.
Objects on the other hand, have rules defined by the PHP program they are running in. These rules are what we call classes.
While every array plays by the same rule, each object plays by the rules of objects and by the rules of the class used to create them.
Instances
Sometimes the words “class” and “object” are used interchangeably, but they should not be. As I said above, classes are rules for creating objects, but those objects do not exist until they are instantiated.
Class instantiation happens using the new keyword. If I want an instance of the WP_Query class, I could create one like this:
Instantiating a class and calling a function are very similar, but function calls are not preceded by the new keyword.
When a class is instantiated, its constructor is called immediately and any arguments injected into the class are passed to the constructor. Constructors are an example of a PHP magic method. They are a way to inject data directly into the object and also to run code immediately on instantiation.
As you noticed, I passed an array of arguments to the WP_Query class when I instantiated the object. If you look inside WP_Query’s constructor, if the one argument it accepts isn’t empty, that argument is passed to the query method of that class.
The query method sets off the process that WP_Query is used for — querying the database to get posts. Separating that method out from the constructor is good design as it keeps the constructor from taking on too many responsibilities. It also allows us to control when the query is run. While most of the time it is fine to run the query right away, the flexibility that separating query() from __construct() is very useful.
While WP_Query has lots of rules, they apply to all objects or WP_Query, that does not mean all objects of WP_Query are the same. That’s because their properties will contain different information. For example, look at this code:
We now have two instances of the WP_Query class. Each one will contain totally different posts in their posts property, but the way that those posts got there and the way that they can be accessed or changed is the same.
What An Object Is An Instance Of
In the last section, I talked about objects that were instances of WP_Query. What we mean is that these objects were created using the WP_Query class. But, let’s not forget that classes can be subclassed. When an object is an instance of a class that extends another class, then it is considered an instance of both classes.
This is an important distinction because it determines how the function is_a() will function as well as type hinting rules. If I make a class that extends WP_Query, it will be considered an instance of WP_Query. This is one of the features of object inheritance that makes it so useful.
Let’s say you had an abstract class called “social” and two classes that extended it called “Facebook” and “Twitter”. You could identify the instance of these classes by checking if they were instanced of “social.”
What Is $this?
Inside of a class, you can access the current instance using the special variable $this. Outside of a class you can not use $this or PHP will throw an error. Inside of a class, you use $this to access properties or methods of that class.
The variable $this always refers to the current object, no matter which class in the inheritance hierarchy you are. On the other hand the keyword “self” refers to the current class, not the current instance. Static properties are not unique to a specific object, they are unique to a class.
“True” Object-Oriented Programming
A lot of time we see classes that don’t really represent a discernible object. Instead, they are a collection of related functions. In this case, the class acts as a namespace. This may or may not be a bad thing.
We always should test these situations on a case by case basis. In my opinion, it comes down to whether the code could be rewritten as a collection of functions that were not contained in a class. I say this because writing a class, just to avoid using unique function prefixes is no excuse to use a class, and is less performant and less flexible.
If the only utility of a class is avoiding using unique prefixes, then why not just group the functions into a file and use a namespace in that file?
But, keep in mind that classes have inheritance, visibility, and properties, which a group of functions do not. These are perfectly good reasons to use a class, even when it is not “true” object-oriented PHP.
In these situations, you are often dealing with a class where one instance is indiscernible from the next. Instantiating these classes into objects and tracking those objects is almost always a bad code smell and unnecessary. In these situations, it is often better to declare all methods of the class static, so instantiation is unneeded.
Many people will tell you that just because you’re using a class doesn’t mean you are using object-oriented programming. They are right. Just don’t forget that object-oriented programming is not categorically better than the alternatives.
0 Comments