OOPs………… !!!!

Jugal Thakkar

Most of us have gone through books with various definitions/introductions on Object Oriented Programming, these contain then-jargon like abstraction, polymorphism, inheritance, encapsulation, etc. in the very first chapter. How to easily understand all that when we are just starting? To some, it’s too much of spices when they don’t know what common salt is.

To begin with, all we need to know is a class. Class, in simple words is Kind or Family. Let’s say I have a calculator, I like to call it Jugal's Calculator giving a sense of possession. So now, we ask Jugal's Calculator is of what kind? The simplest kind we can identify without knowing the brand or functionality this calculator gives, would be of kind Calculator. It so happens that John Doe also has a calculator, which he calls JDC. From what we know, JDC also belongs to the family of Calculator. So here, Calculator is our Class and Jugal's Calculator & JDC, which are things of those kind, are called objects or instances of the class Calculator.

Object Oriented Programming, as name suggests, revolves around these things or objects that we just defined.

  • What (but not how) this object can do? (encapsulation)
  • What families does the object belong to? (abstraction)
  • What it is made up of? (composition)
  • Does another object already do a part of what I am supposed to? (inheritance)
  • And more complex (yet interesting) things like Polymorphism, etc

We have very loosely defined these terms for understanding purposes, the real meanings will be clearer as we get a better hang of their usages. I also like to call it Real-World Programming. RWP??? We create data structures/classes with the aim of having an analogy to the real world.

With all that said, let’s see how to create a neat class. Things we need to keep in mind are,

  • What will be the primary objective of the objects of this class?
  • What data will they need to have, in order to do these actions efficiently?

These two questions would allow us to define the public part of the class. I would love to use interfaces here, but want to keep things simple till we make them complex ;). If you think you know the answers to these two questions, think again =D.

So, if we have to design a very simple calculator, which even our great grandfathers might not use, what would be our class(es)? Let’s say, this calculator can only perform add and subtract.

public class Calculator{
 public int Add(int x,int y){  
 } 
 public int Subtract(int x,int y){  
 }
}

And we are all happy? Not me. This wouldn’t be wrong or not serve the purpose, just that it doesn’t translate into the real world analogy concept. How many of you have a calculator that asks for the operator first (Add) and then the two numbers and gives the answer back to you? The way calculators work is to give first operand, give operator and then second operand and get the result.

Lets answer the first question.
Add? Subtract? Add & Subtract? I would say, the primary objective of the calculator is to simply Calculate!! Add & Subtract are merely types of calculations.

Now the second question.
It just needs two operands and an operator.

public class Calculator{
 public int Operand1;
 public int Operand2;
 public char Operator;
 public int Calculate(){  
 }
}

So now are we happy? I ain’t yet. This still isn’t real world. A calculator consists of buttons and a display. This is now real world. So we introduce two more types of objects, Button & Display. This is how OOP is supposed to work. Breaking down responsibilities and delegating them so you only do what is your primary role.

In this new approach, the user doesn’t actually interact with Calculator directly, it uses the buttons, which are part of the calculator. The user can press a button. In fact that is all the user can actually do 🙂 Making all the above class members (Operand1, Operand2, Operator, Calculate()) not directly accessible to the user. Thus, they would all become private and an array of Buttons would be the only thing public to the user. Each button would merely expose a method (say, Press()) for the user to interact. Also there would be DisplayPanel that user can view.

I will refrain from going into the implementation details and aim to highlight the process of coming up with the right classes and not implementing them.

public class Calculator{
 public Button[] Buttons;
 public DisplayPanel UserDisplay;
 private int _operand1;
 private int _operand2;
 private char _operator;
 private int calculate(){  
 }
}

public class Button{
 public void Press(){  
 }
 public String DisplayName;
}

public class DisplayPanel{
 public void Show(string displayString){  
 }
}

A question may arise, that why not break up the Button or the DisplayPanel into smaller classes too? Yes, sure go ahead, but for the purpose of creating the class Calculator, we are only concerned about the Button and the DisplayPanel, that’s the beauty of abstraction. You are least bothered of the implementation. Calculator doesn’t care if the DisplayPanel consists of LEDs or Printer or whatever, it only knows that it can call on the method Show() with the string it wants to display.

This process may appear to be inundating at first but would come naturally, like any spoken language that you know, once put into practice. Also the real life correlation helps others to quickly understand your code and approach.

Latest posts by Jugal Thakkar (see all)