Creating a Vehicle OOPs way

While interviewing entry-level developer(s), to test their understanding of OOPs concept more often than anything I ask them to design a Real-life object in code viz. a vehicle.
I see a lot of candidates making wrong choices when designing such simple and abstract concepts, Through this article, I'll try to share my understanding of how these objects can be designed.

Object oriented design is different than object oriented programming.

The most common trouble I see people have is what should be defined as an interface, a class, or an abstract class. To find the right answer one should approach this problem from a different angle. For the given case of a vehicle, First, think what classifies as a vehicle? and the possible objects coming to mind are:

• A car
• A bus
• and maybe a Scooter or Motorcycle

Now keeping these images in mind, try to think about what makes you recognise a car as a car and distinguish it from other objects. What helps you identify a car uniquely. You may imagine things like:
Shape, 4 wheels, steering wheel, engine, colour of the car, license plate, and many other things.

Now once you have visualised a vehicle type, a solid structure (a specific car) and its behaviour (like opening the door to allow passengers in the car, it can be driven around), you have almost solved the problem.

Now the rule of thumb I apply here is:

segregating the information into two parts Attributes and behavior.

eg: Colour of the car is an attribute, also all the vehicles auth to have a colour. A car's capability of getting driven is a behaviour. And now we break things into classes, abstract classes, and interfaces.

Another important lesson here is:

1. Interfaces should be used to define behaviour
   Check Java for example, It has interfaces like Callable, Cloneable, Comparable, Formattable, Iterable, Runnable, Serializable, and Transferable all of these popular interfaces define behaviour and not data.

2. Use abstract classes to define/carry Attributes
   The good example would be Colour of your vehicle. It's a common attribute among all the vehicles.

3. Create Classes for specific details and rules
   A car will have doors and a bike will not have doors. So adding door-related information to the Vehicle would not make any sense.

Please keep in mind you may find multiple levels of abstractions in your design, like almost all drivable are likely to have doors and box-like structures while almost none of the ridable vehicles. So based on the scenarios and needs of the system you may need to define multiple levels of abstraction. But the most important thing to remember here is not to merge the drivable interface with such attributes which maybe be common among all drivable objects.

And now is the time for an example, for the sake of simplicity I've chosen very few attributes and behaviour here.

abstract class Vehicle {
    protected String colorHex;
    protected int capacity;
    protected String licenseNumber;

}


interface Drivable {
    void drive();
}


class Car extends Vehicle implements Drivable {

    private int door;

    public Car(String colorHex, int capacity,
               String licenseNumber, int door) {
        this.colorHex = colorHex;
        this.capacity = capacity;
        this.licenseNumber = licenseNumber;
        this.door = door;
    }

    @Override
    public void drive() {
        //Some logic to drive the car
    }
}

public class Sample {
    public static void main(String[] args) {
        //the requirement is to drive from a point A to B so we are using the drivable reference of the object
        Drivable car = new Car("000000", 4, "IND1212", 6); // Well I like black cars :P
        car.drive();
    }
}

Now I'm going to go back and ask another question here, should licenseNumber qualify as an abstract attribute? what would be the identity of such objects? Give it a thought, We may discuss it some other time. Till then happy Coding... 😊