When it comes to talking about object-oriented programming (or OOP), you’re likely to hear about The Three Pillars of Object-Oriented Programming or The Four Pillars of Object-Oriented Programming.

Depending on your background, you may have already heard of them, know what they are, and don’t really need to dive into it too much. But if you have not, I believe understanding them is foundational to object-oriented programming.

We’ve covered the whole Analysis phase of Object-Oriented Programming:

  1. Analysis, Part 1
  2. Analysis, Part 2
  3. Understanding Customer Expectations
  4. Statement of Work
  5. Terms and Conditions

With that said, let’s get into the design and implementation discussions. After all, this is what’s many people want to jump to anyway, isn’t it?

Two Pillars of Object-Oriented Programming: Part 1 of 2

Before writing any code, I’d like to do two posts about the four points of object-oriented programming (because I’m one of those who subscribes to the idea that there are four).

[restrict paid=”true”]

Two Pillars of OOP

Again, understanding these is key to understanding the foundation of object-oriented programming. Without them, it’s going to be hard to navigate the rest of what’s to be discussed in future posts.

With that, let’s talk about each of them. We’ll cover the first two in this post and the final two in the next post.

1. Abstraction

Generally speaking, this is the key to writing object-oriented code. By that, I mean everything that is contained within a class. We abstract the idea of something into a class. In many books, we’ll see things like Animals or Cars represented as classes.

This works, in theory, but in practicality, we’re not programming animals nor are we programming cars (though I guess at this point in history, you could argue we are, but I digress because you know what I mean).

Instead, we’re going to be abstracting ideas into their classes. And there’s a key idea here:

A class should represent a noun.

That is, you shouldn’t have a class that represents something like “Running.” Instead, you may have something that runs and, thus, runs would be a method. And that’s the general breakdown of how abstraction works:

  1. The thing that’s to be represented is the class,
  2. The stuff the thing does are its methods,
  3. And the way you describe the thing can usually be done so via its attributes or properties.

This doesn’t mean that we don’t have functions or methods that modify its properties, but the three points above are good rules of thumb. So when you’re designing a class, you can ask things like:

  • Am I writing something?
  • Am I writing something to do?
  • Or am I writing something that desribes something?

Because if you’re writing an action, it’s likely done by something (because things take action – they do stuff). And if you’re describing something, then it likely refers to something (when’s the last time you described nothing?)

Make sense?

 

2. Encapsulation

So if we’re writing classes – good classes – then we need to be writing them in such a way that we’re properly encapsulating their data. And encapsulation is really just a “big” word that refers to the idea of managing its responsibilities (or keeping track of its data).

So, for example, if we were writing a class to represent a WordPress post then we’d have a class named Post with properties like publish, update, delete, postData, publishDate, lastUpdatedDatadeletedDate and so on.

Then we’d have functions specifically designed to take action on an instance of the the Post class.

Case in point, we may…

  • publish,
  • update,
  • or delete a post

These methods will likely be exposed in such a way that other classes can take advantage of them. Furthermore, these methods will likely also take advantage of other properties such as the publishDate or the deletedDate.

And this is where the concept of visibility comes into play. In object-oriented programming, encapsulation not only refers to the idea of the information that a class contains but how it exposes the data.

These are done via three ways all of which are defined below:

  1. public properties and functions are available for anyone to use them; however, public properties are usually not exposed. Instead, we make sure they can be modified by a public method.
  2. protected properties and functions are available to be used by the class and any other class that inherits information from it. This will be discussed in more detail in the next post.
  3. private properties and functions are those exclusively meant to be used within the context of a given class. These may be properties used to track internal statuses or methods used to work as helper functions for public functions to complete their work.

As we continue through this series, we’ll see the role that each of these plays when writing clear, easy-to-follow, well-architected classes.

For now, though, it’s important to understand that these words, public, protected, and private, are referred to as visibility modifiers because they, as you can ascertain, manage the visibility of a method or a property with respect to its class and the classes that inherit from it and that interact with it.

Speaking of inheritance, I’ll be talking about that in the next part of this series.

 

Abstraction, Encapsulation, and WordPress

The Bad News: Classes in WordPress

Here’s the thing: In WordPress, we often see very, very large classes. This is not a good thing. In fact, these are anti-patterns called god-classes (the idea being that you have a single class that knows everything).

And when you have a god-class, it seems convenient because you can drop all functionality into one place. But

  • it’s hard to test,
  • it doesn’t scale,
  • it doesn’t play nicely with another class (let alone classes or third-party libraries),
  • it doesn’t adapt well to change.

Ultimately, when you’re doing that, you’re not doing object-oriented programming. You’re taking functions and throwing them into a class. And we want to get away from that.

The Good News: Writing Classes On WordPress

This raises a question, though: Why try to learn object-oriented programming with WordPress if it’s not a solid example of object-oriented programming?

That’s because you can still write good object-oriented code on WordPress. It can still interact well with WordPress, and it can still play nicely with many other aspects of WordPress.

I know it sounds counter-intuitive, but as we dive deeper into writing object-oriented code on WordPress, this should become clear.

[/restrict]