Tag: Abstract Classes

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.

Continue reading

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.

Continue reading