Demystifying Object-Oriented Programming: Pt. 2
~ cat "Demystifying Object-Oriented"~ cat post <<
Welcome back! At the end of our last post, we hit a bit of a roadblock. We had successfully organized our F1, PickupTruck, and SUV classes to inherit from a base Car class. But then, we were faced with a new challenge:
A bicycle, a speedboat, and an electric car. They are all vehicles, but trying to force them into a single Vehicle inheritance hierarchy would be a nightmare. A speedboat doesn't have wheels, and a bicycle doesn't have an engine in the traditional sense. A simple extends Vehicle starts to feel clunky and wrong. How do we model things that share behaviors but are fundamentally different things?
The answer lies in moving beyond the idea that everything must share a common ancestor and instead thinking about what they can DO.
Interfaces: A Contract of Behavior
Let’s ask a different question. Instead of asking what these objects are, let's ask what they have in common from a user's perspective. A person can:
- Steer them
- Make them go forward
- Slow them down
In Object-Oriented Programming, when we want to guarantee that different classes share a common set of behaviors, we use an INTERFACE. Think of an interface not as a blueprint for an object, but as a contract. It’s a list of methods that a class promises to implement. It defines WHAT a class can do, but not HOW it does it.
Let's create a contract for anything that can be driven. We'll call it Drivable.
// Interface
public interface Drivable {
void turnLeft(double degrees);
void turnRight(double degrees);
void accelerate();
void brake();
}
