Abstract Classes, Part 2 – Abstract Classes and Interfaces

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.

Abstract Classes and Interfaces


Read More

Abstract Classes, Part 1 – Abstracting Behavior

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:

  1. Define what abstract classes are,
  2. Describe the different in abstract classes and interfaces,
  3. Help decide when you want to use one over the other.

With that said, here’s the whole idea behind abstract classes.

Read More

Object-Oriented Programming: Understanding Interfaces

At this point, I’d say that the foundations of understanding object-oriented programming have been laid.

Specifically, I’ve covered:

  1. Abstraction
  2. Encapsulation
  3. Inheritance
  4. Polymorphism

And, yeah, there’s some debate as to what constitutes the foundations (that is, some don’t toss polymorphism into the mix though I do). But the above four should provide a solid foundation off of which to continue building your object-oriented programming skills.

There are more, but I don’t think they are as deep, detailed, or tough to understand as some of the aforementioned concepts. Then again, different things come easier to others.

Understanding Interfaces

At any rate, the next two topics that are important to understand are:

  1. Interfaces
  2. Abstraction

I’ll talk about each separate but make sure that you’ve read the Fundamentals series first because the above two topics will allow you to rely on them and take advantage of them.

Vague, I know, but let me explain and then go from there.

Read More

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

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.

Two Pillars of Object-Oriented Programming: Inheritance and Polymorphism

And in this post, I’m going to cover the final two:

  • Inheritance,
  • 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.

Read More

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

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).

Read More