As I mentioned in the first post of this series, you’re often going to hear about The Three Pillars of Object-Oriented Programming. You may also hear about The Four Pillars of Object-Oriented Programming.
And it’s not that there’s a total of seven or anything like that. Instead, it’s more about what people consider to be foundational to OOP: Are there three or four major concepts?
You can surmise from the previous article (let alone the title), I believe there are four.
And in this post, I’m going to cover the final two:
- and Polymorphism
If you’ve done any type of object-oriented programming prior to reading this article, you’ve likely heard of at least one of these.
Regardless, let’s take a look at each of them in more detail.
Two More Pillars of OOP
Before jumping into each of these, I want to be sure that you’re caught up in what we’ve covered so far.
A Word About Analysis
I won’t belabor the point, but the whole reason I’m now talking about object-oriented fundamentals is because we’re moving into a different phase of this material. We started off covering the Analysis phase which included:
- Analysis, Part 1
- Analysis, Part 2
- Understanding Customer Expectations
- Statement of Work
- Terms and Conditions
Now To Development
And now we’re on to the development phase. Some may call it fundamentals (but I content you can’t do good development without the fundamentals so there’s that(.
If you’ve not read the previous post, I recommend doing so before continuing as it covers the concepts of Abstraction, Encapsulation, and how it relates to WordPress.
The concept of inheritance is pretty easy to follow. That is, one class can inherit attributes of another class. I’ll give a few examples of this in a moment, but let me provide a working definition for the purposes of this post:
Inheritance refers to the idea that one class, although it has its own impementation, literally inherits properties, functions, and general implementation from a parent class.
Example 1: A Document
In very simple terms, let’s say you have a class called Document and a document has a title and it has content. Then there’s a subclass of document that has attributes for a date and time. We could call this a PostDocument or a PageDocument.
That is, the PageDocument inherits the properties and attributes of Document while also adding its own implementation to it. Make sense?
If not, don’t worry. It doens’t always “click” at first so let’s look at another example.
Example 2: A Message
Let’s say that we have a Message class. A message typcally has two properites:
- 1. A sender,
- 2. A recipient.
It’s fair to say there are different types of messages though, right? That is, perhaps we have an EmailMessage or maybe we have a TextMessage.
An EmailMessage still has a sender and still has a recipient but it has so much more, right? It has things like:
- a subject line,
- an optional attachment,
- another set of senders to whom it’s sent,
- support for copying others to the message publicly or privately,
- and much more.
A TextMessage on the other hand won’t necessarily have all of the above. Let’s assume we’re talking about a basic SMS message (versus a rich text message in something like Hangouts, Telegram, iMessage, or whatever else is out there).
This class will:
- be tied to a phone number,
- may include a group of other recipients all of whom are public,
- a carrier (that is a cellular provider),
- a maximum number of characters that it can contain
- the ability to split a single message into multiple messages if the maximum number of characters exceeds a certain amount of characters.
But it still raises questions about properties and methods (or, more generally, implementation, right?)
A Word About Implementation
When it comes to object-oriented programming, we have what we call access modifiers. Perhaps you’ve read them elsewhere referred to as, say, visibility modifiers or something like that.
It’s all the same.
In short, these modifiers can be defined as:
Keywords that control what others classes have access to the information at hand.
Lucikly, this part is straightforward to understand:
- private properties and functions are only accessible to the class in which they are defined. This means that PostDocument cannot use anything in Document that is marked as private. For all intents and purposes, PostDocument is not even aware this information exists.
- protected properties and functions are accessible to the class in which they are defined and any class that as a descendant. That is, any class that inherits data from the base class or the parent class has access to it. So, unlike private implementation details, the PostDocument can access information from Document if it’s marked as protected.
- public properties and functions are accessible to anyone. This has nothing to do with inheritance, really, but more with encapsulation, if anything. Instead, it’s all about deciding what we want other objects to access.
So how is implementation handled? This varies from language to language but PHP does not support what’s called “multiple inheritence.” Simply put, a given class in PHP can only inherit (or extend) one other class. Not multiple classes (some languages support this).
When you extend a class, the subclass inherits all of the public and protected methods from the parent class. Unless a class overrides those methods, they will retain their original functionality.
In our example, we cannot introduce another class such as WrittenDocument that inherits from PageDocument as well as PostDocument. It’s either one or the other. And it’s worth noting that if it inherits from PostDocument it also inherits information from Document because it’s a subclass of a subclass of a class.
Now that we have a basic definition of inheritance in place, we can talk about polymorphism. The good news is that it’s a large, weird word for a very simple concept.
The bad news is that we haven’t talked about interfaces or abstract classes. These are coming but they are considered part of the four pillars, so don’t worry about them right now.
Instead, think of it way:
Polymorphism allows us to refer to a class of one type when it may be declared as another type.
It still may be confusing, but remember our, say, Message example above? We can instantiate an SMSMessage class that extends the Message class and then call certain methods on it.
The SMSMessage may have a method that the Message class has. And if the class has been instantiated as an instance of the SMSMessage class, then it will call that method. Similarly, if it does not have a method but its parent class, Message, does have it, then it will call that method.
Sometimes, it’s easiest to understand this in code so let’s do that.
First, let’s define our Message class:
Then let’s define our SMSMessage class. Notice that it doesn’t have a receive() function. This will be important momentarily:
Now, let’s instantiate our Message class and call a few methods:
And let’s do the same using the SMSMessage class:
Inheritance, Polymorphism, and WordPress
Here’s the take away (and we’ll explore this more when we get into interfaces and abstract classes): When a class extends another class and it doesn’t have the implementation details that its parent class has, the parent’s implementation will be used.
Another way of thinking of it is “working up the chain of command.” It will start with the class lowest to what we’ve created. In our example above, that’s the SMSMessage. If it doesn’t find it there, it will move up to the class it extends. (And if it doesn’t find it there and that class extends a class, it will try there.)
The whole polymorphic thing is this: We’ve instantiate a class of one type, SMSMessage, but it’s using the implementation of a class of another type (that it inherits, yes, but that’s different nonethelesss).
Writing Classes On WordPress
Finally, I’d like to leave you with this: I’ve mentioned something similar to this in the previous post but I want to reiterate it here.
Regardless of how many of these concepts WordPress core uses, it doesn’t matter because we can write high-quality, object-oriented code on WordPress that interacts with WordPress and that plays nicely with WordPress (and other third-party code – not always, but many times).
What’s Up Next?
Next, we’ll be looking at interfaces and abstractions.
These are still fundamental to object-oriented programming, but if you’ve understood the previous two posts, you’re set up for a solid experience with the upcoming conccepts.
And if not, don’t worry! You can always talk about it in the comments or we can chat about it more via email.