A really common jargon that gets thrown around in the world of software is ‘OOPS’. This does not refer to a mistake, as in ‘oops!’. On the contrary, OOPS in software in mostly a right decision. OOPS is an acronym for Object Oriented Programming System. It is one of the ways to think about software, 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?
As mentioned in the intro, object-oriented programming is one of the several ways to approach a problem for which software is being written. Let’s think about 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. The dust needs to be disposed. 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 and most likely allows the problem solver to go for the minimum possible solution that solves the problem, e.g. sweeping with a broom.
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 gone deeper and given emphasis to the ‘things’ 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 ‘thing’ (floor) that was holding another ‘thing’ (dust) so far and now handing it off to yet another ‘thing’ (waste area).
Thinking about problems in terms of ‘things’ that you can visualise and touch can give you really innovative solutions. You can then think about other ‘thing’s that you can introduce in the system as part of the solution. The maker of vacuum cleaner perhaps adopted the approach of thinking about the problem of cleaning the floor as an interaction between things. That is maybe why he 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 ‘thing’s). The dust can then be dumped off the bag into the waste area.
I have use a simple word called ‘thing’ in the post so far. But in object-oriented programming, we use the word ‘object’ to refer to these ‘thing’s. Software objects are often analogies of things that we use in the real world. That is why object-oriented software has been used for so many innovative solutions, be it for banking or for launching a satellite into space.
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 should have these two properties. When a 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.
Thus, for a new account to be created, there must be a blueprint that suggests that a newly created account must have an ID and a balance. 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 properties are called attributes in the object-oriented world.
Also, bank accounts support operations such as withdraw and deposit. These 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 paranthesis like so: withdraw(amount), deposit(amount).
Parent, children, inheritance and overriding
Let’s talk about hierarchies among classes with an example, something we use everyday. Paper. A sheet of paper has a colour, a height and a 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 the standard A4 paper. We can also call it 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 colour patterns such as marble-work or geometric shapes. Not much is written on wrapping paper. The 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. In a sense, each paper is different from the other. However, they also exhibit common properties as mentioned in the opening paragraph of this section (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.
Let’s talk about inheritance. 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’.
If you have ever driven a car, you will know that you need to use three functionalities. You need to accelerate, brake and steer. That’s all you need to know to drive a car. You do not need to know how each of this works. 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 functions that must be available. In object-oriented terms, an interface contains a set of methods. A class then agrees to ‘implement’ the interface. That class must then compulsorily provide a way for something to happen when each of the methods is used. Not providing a functionality for one of the methods in the interface is like violating a contract. That class would be ‘illegal’.
Both you and the manufacturer agree that a car must provide the ability to accelerate, brake and steer. A car manufacturer must provide at least those functionalities for his/her car to be legal.
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 program using only object-oriented concepts. Java is more compliant than Ruby when it comes to enforcing every rule in the world of object-oriented programming.
The other languages can use either object-oriented concepts or process-oriented concepts (check the example of cleaning the floor in this of the blog).
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 on 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 ‘thing’s 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 blogs, we will see how object-oriented concepts are used as a solution for common patterns that occur repeatedly.