Abstract Classes, Part 1 – Abstracting Behavior We have abstractions and abstract classes in object-oriented programming. What's the difference?

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.

Abstracting Behavior

First and foremost, there’s a difference in abstraction and abstract classes. The former refers to the idea of representing something in programming; the latter refers to an actual way to write code.

⚠️ Hey, Wait!

Thanks for your interest in this article! Note that it's available to members only. If you'd like to review this (and have access to all previous and future articles), check out the membership benefits.