Objects vs Classes
Which one to use when
Created by alekksall - www.freepik.com
Introduction
I always wondered, “Although definition of a Class states that it's a Blueprint to create different Objects. In reality how to decide that something should be represented as a class or an object”. Object has State and Behaviour. Class defines what kind of states can be stored in the object but the behaviour definition is same.
Use Case - Modelling Vehicles
Let's take an example of three types of Vehicles : Bike, Car and Auto-Rickshaw. All three are specialised kinds of Vehicle. Based on the abstraction we can say that for all these vehicles to move they need wheels. Although the number of wheels differ based on the kind of vehicle. There are two different ways of modelling it :
Single Class Multiple Instances
Model all three using a non-abstract Vehicle class and have noOfWheels value as a state which will enable us to create three different instances which are identified based on the number of wheels
Separate Classes
Separate classes for all three types with a single abstract parent class Vehicle having noOfWheels as a Protected field which will be inherited by the child Classes.
Let's go with Single Class Multiple Instances Approach. Suppose we create on instance of Vehicle class with noOfWheels as two, then it's an instance of Bike. Similarly for Auto-Rickshaw and Car we can have value of noOfWheels instance variable as three and four respectively. The Objects approach suits so far since we have all three instances having different states but same behaviour of movement. Now let's say all three have different turning radius. It's also a state of the object hence we can define that as an instance variable. Hence we can still go ahead with Single Class Multiple Objects approach.
Created by rawpixel.com - www.freepik.com
Lets make things interesting
Doing a wheelie is possible in bikes only. Now is the time to create a separate class for the Bike since its a behaviour specific to bike and not to Cars and Auto-Rickshaw. Hence a rule of thumb is to start with Generalisation then go towards Specialisation. It helps in Agile Modelling since we gradually model the details based on our knowledge of the entities. Most of the projects start with little information and slowly evolve when more details are available. Going with top down approach is good here since we can have clear abstraction of our software. Now we have a Vehicle class to instantiate Car and Auto-Rickshaw and a Bike class to instantiate Bike Object.
Deep Dive Further
Let's understand the fact of safety precautions of a rider. Ideally the behaviour to enable safety precautions of a rider is different for a Car and Bike. A Bike rider should wear a Helmet and Car driver should wear Seat Belts. ( Note : We are taking a single precaution example here to understand the concept. There may be other precautionary measures ). Now is the time to create a separate class for Car as well since the safety precautions enablement is different for Car and Bike. We can still use the Vehicle class to instantiate Auto-Rickshaw Object since so far they don’t have any specific safety precautions for the driver. ( Note : Its under discussion and implementation to have safety features and precautions for the Auto-Rickshaw driver ). The current classes we have is : Vehicle, Bike and Car which are used as :
Vehicle class to instantiate Auto-Rickshaw Object, Bike class to instantiate Bike Object and Car class to instantiate Car Object. We still cannot have an abstract method in the parent class Vehicle to enableSafetyPrecautions since its not available for Auto-Rickshaw object.
Class Modelling
Summary
Always follow the Generalisation to Specialisation approach ( TOP-DOWN ) for Agile Modelling. Deciding factor for going with classes or objects is whether something can be modelled as a state or a behaviour. Dictionary meaning of State is particular condition something has at that instant. It's a constant thing at that instant. Behaviour means to do something.