When I started this series, I talked about the four pillars of object-oriented programming. Each of these topics is listed and linked below.
At this point, I’d normally want to begin moving on to the next topic. Before doing so, though, I’d like to spend one more post exploring the concept of polymorphism.
In my career, thus far, I’ve seen few topics give those getting into object-oriented programming more confusion and problems than polymorphism. So I’d like to discuss it a little more in-depth within the context of object-oriented programming and outside any particular framework or application (like WordPress).
In this post, I’ll do a quick review of what we’ve discussed thus far, then hop back into polymorphism.
In the previous post in this series, I walked through:
- the basics of abstract classes,
- how to implement them,
- and provided working code examples.
And though I think understanding abstract classes are key in laying a strong foundation for object-oriented programming, I often see that it can be confusing when it comes to comparing them to interfaces and knowing when to use them.
About a month ago, I wrote about one of the pillars of object-oriented programming (specifically being Abstraction). In the post, I defined abstraction as the following:
Instead, we’re going to be abstracting ideas into their classes. And there’s a key idea here: A class should represent a noun.
And though that’s still true, the idea of abstract classes is something that’s different in object-oriented programming.
It sounds confusing, right? That is:
- on one level, we have abstraction being defined as the idea that we take an idea and represent it in a class,
- on another level, we have abstract classes which are used to help define functions that subclasses must implement.
And if that isn’t confusing enough, we mix this in with interfaces which provide a contract implementing classes must follow, and then we mix it with abstract classes which define methods that also must be implemented but can also implement methods of their own.
Confused yet? No worries. The whole point of the next three posts is to do the following:
- Define what abstract classes are,
- Describe the different in abstract classes and interfaces,
- Help decide when you want to use one over the other.
With that said, here’s the whole idea behind abstract classes.
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.
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:
- Analysis, Part 1
- Analysis, Part 2
- Understanding Customer Expectations
- Statement of Work
- 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?
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).