A really common jargon that gets thrown around in the world of software is ‘OOP’. This does not refer to a mistake, as in ‘oops!’. On the contrary, OOP in software is mostly a right decision. OOP is an acronym for Object-Oriented Programming.
OOP is one of the ways to think about a software solution, design its architecture and use an appropriate programming language to write it. In this post, I will explain to you some concepts of object-oriented software. If you are a future software developer, this post will make it easy for you to understand. Even if you never intend to be a software developer, this post will make you look at software from a different perspective.
What exactly is object-oriented programming?
Consider a common problem: cleaning dust from the floor.
Here is one way to think about the process. The dust needs to be removed from the ground. It needs to be disposed of. Note the emphasis on the key verbs in the sentences: to remove and to dispose. This sums up the steps needed in the process of cleaning the floor. This type of thinking is very pragmatic. The problem solver to go for the minimum possible solution that solves the problem, e.g. sweeping with a broom. This is process-based thinking.
Another way to think about the problem is this. There is dust on the floor. And we have a waste area such as a dustbin. Our aim is to transfer the dust from the floor to the waste area. In this approach, we have though differently and given emphasis to the ‘things’ or objects that are involved: dust, floor and waste area. We have determined that the dust needs to move from the floor to the waste area, i.e. one object (dust) that was part of another object (floor) so far is now handing moving to yet another object (waste area). This is object-based thinking.
What does it make possible?
Thinking about problems in terms of objects can give you really innovative solutions. You can visualise them and feel like you are holding them in your hand. You can imagine how they interact with other objects. You can even think about other objects that you can introduce in the system as part of the solution.
Object-based thinking mimics the real world more effectively than process-based thinking. Objects allow you to find relations, interactions and solutions you’ll not clearly see in processes.
The maker of vacuum cleaner perhaps adopted the approach of thinking about the problem of cleaning the floor as an interaction between things. Maybe that is maybe why he/she was able to introduce the concept of a machine that sucks the dust off the floor into a bag (note that machine and bag are more ‘things’). The dust can then be dumped off the bag into the waste area.
Let’s look at some concepts that are commonly used in object-oriented programming. It’s time to do some jargon-busting.
Classes and Objects
Let’s talk about bank accounts. A bank account has two properties: ID, that is used to distinguish it from other bank accounts, and a balance, the amount of money that is currently in the account. In fact, all bank accounts ever created have these two properties. When a new bank account first gets created, it should automatically have these two properties. The ID should be generated automatically such that it is unique from the IDs of the other bank accounts. The balance is 0 (zero) to start with.
There must be a template or a blueprint that suggests what a newly created account looks like. This blueprint is called a ‘class’. An individual bank account itself is called an ‘object’. The programmer defines the ‘Bank Account’ class as the blueprint for bank accounts. The programmer also makes sure that when the clerk at the bank instructs the software to create a new bank account for a new customer, a new object based on the Bank Account class is created in the system.
An object is also called an ‘instance’ of a class. So, a bank account with ID XYZ123 is an instance of ‘Bank Account’ class.
Attributes and methods
We mentioned that bank accounts must have a unique ID and a balance. These are called attributes in the object-oriented world.
Also, bank accounts support operations such as withdraw and deposit. The operations are called methods. Methods will often have options accompanying them. E.g. you always specify how much to withdraw and how much to deposit. These options are called parameters. Methods with parameters are represented in parentheses like so: withdraw(amount), deposit(amount).
Parent, children, inheritance and overriding
Let’s talk about hierarchies among classes with an example we use everyday. Paper. A sheet of paper has a colour, height and width. These are the attributes of paper. A sheet of paper can be written on or folded. These are the methods of paper.
Now, let’s dive a little deeper and think about the different types of paper that are available. First, there’s blank paper. It is perfect for printing on. However, I wouldn’t call it the best fit for writing on. For this purpose, there is ruled paper. A ruled paper has additional attributes such as the spacing between lines. Another category of paper is wrapping paper for gift-wrapping. These sheets will often have coloured patterns such as marble-work or geometric shapes. You hardly write on wrapping paper. Written content is typically a greeting to the receiver of the gift.
As you can see, each of the different types of paper has its own purpose and properties. Each paper is different from the other. However, they also exhibit common properties, i.e. colour, height, width, the ability to be folded.
To represent this relation, this is what we do in the object-oriented world. There will be four classes named ‘Paper’, ‘Blank paper’, ‘Ruled paper’ and ‘Wrapping paper’. The latter three are set up as children of ‘Paper’ class. ‘Paper’ is called the parent class.
By being the children of the ‘Paper’ class, the other three classes automatically get the properties and methods of the ‘Paper’ class, i.e. colour, width and height properties and the fold and the writeTo method. That behaviour is ‘inherited’ from the parent. In addition, the classes will have their own properties and methods.
Note that a child class does not need to obey the parent class’s behaviour while inheriting it. E.g. ‘Blotting paper’ is a type of paper that absorbs ink and cannot be written to. While other papers will display whatever is written on their surface, a blotting paper will absorb the ink. Hence the writeTo method of ‘Blotting paper’ will alter the functionality of that method. This ability to alter the behaviour of a method inherited from the parent is called ‘overriding’. The child class overrides the functionality suggested by its parent class.
If you drive a car, you know three functions, i.e. accelerate, brake and steer. That’s all you need to know to drive a car. You do not need to know how each of these works behind the scene. That’s the work of the manufacturer.
A petrol car manufacturer makes sure that more petrol is injected into the piston when you rev the accelerator. Likewise for a diesel car manufacturer. An electric car manufacturer makes sure that more current is delivered from the battery. For you, things somehow work when you stamp on the accelerator.
The situation is similar for brakes. Your car may use a disc brake or an air brake. For you, pressing the brakes slows down and stops the car. But for the manufacturer, the discs expand to touch the wheels to cause friction and stop the car. High air pressure causes brake pads to touch the wheels and slow the car down.
This is the power of the interface approach. Both you and the manufacturer start from a common ground, which is an agreed-upon ‘interface’. An interface defines a set of methods that must be available for the user to use. The manufacturer’s responsibility is to provide all those functionalities to deliver a usable car. Otherwise, the car is unusable, even illegal.
In object-oriented programming, an interface contains a set of methods, each with a name. But none of the methods has any functionality. They are left blank. A class then agrees to ‘implement’ the interface, i.e it promises to write some functionality for each of the methods that is required for the interface to be complete. Not providing functionality for one of the methods in the interface is like violating a contract. That class would be ‘illegal’.
Languages that support object-oriented programming
It is hard to list all the object-oriented languages in this post since the number of programming languages has exploded over the past decade. But here are the most popular ones.
Of these languages, Java and Ruby are the only ones that enforce you to create even the simplest program using object-oriented concepts. Purely process-based programming does not exist at all. Java is more compliant than Ruby when it comes to enforcing every rule from the world of object-oriented programming.
It is possible to write purely process-based programs in C++ too, but then that would be a C program. The biggest difference between C and C++ was the addition of object-oriented features. If you don’t want object-oriented programming, you might as well stick to installing C, which is 3 times lighter on both memory and storage.
Book(s) to read
I would recommend that you start with “The Object-Oriented Thought Process” by Matt Weisfeld (Buy from Amazon.in | Amazon.com). This book starts with the basics of what objects are and how you can start thinking about problems in terms of classes and objects.
Thinking about software problems as if they are ‘things’ in the real world gives us a way to visualise software as if it were part of the real world. That makes it easy to think of innovative solutions and to deliver solutions that feel more intuitive for the user. Hopefully, I made the basics of the object-oriented world clear to you. In the next few blog posts, we will see how object-oriented concepts are used as a solution for common patterns that occur repeatedly.