Object oriented programming is a type of programming where both data and code are stored software entities called objects. Lets look at an example to help explain this.
Here is some code where an object of type BankAccount is created. The new object's name is account. A good name I hope you will agree. The account requires an account number, and in this case it's account 12345678. It's an account we'd all like to have, because we are about to credit the account with £5000.
The account 12345678 is now credited with 5000 pounds. Nice. If only all banking were that simple.
So, the class is a computer programming framework of code and data. When an instance of a class is created, that instance is an object. In the example above, the class is BankAccount, and the object is account. Objects can have any number of different operations we can perform on them. Above, the operation placed on the account object was called credit. Let's look at another operation - debit. Our account holder has not paid the due credit card payment in time, so the account is charged a modest £75. Hey, do you think we are a charity? Our bank does not run on fresh air you know.
There, that's better.
That's all well and good, but what's so amazing about objects you may be asking. Consider a selection of the languages that have OO features:
Must be useful somehow then if all those language designers incorporated it into their language. Quite so. To see why, let's take a quick look at some code back somewhere in the Cambrian or Jurassic periods before OO programming was prevalent.
account = read_bank_account(12345678); account.balance = account.balance + 5000; save_transaction(12345678, 5000); account.balance = account.balance - 75; save_transaction(12345678, -75);
Note it's not quite as neat as our previous OO code. But it's doing the same thing, crediting the account with £5000 and then levying that token £75 charge. The OO example is neater because it is better encapsulated, a key feature of OO programming. For the simple examples here, that's not too important. But for a real world banking application, with different types of account, account holders, bank charges, transactions, interest etc the benefits of OO can be considerable.
Another advantage of OO is that it helps developers model the real world entities such as bank accounts and banking transactions into objects. When writing large applications the encapsulation and modularity features that OO provides makes developing software a little easier.
The following code
account = read_bank_account(12345678); account.balance = account.balance + 5000; save_transaction(12345678, 5000);
is replaced with this OO style code-:
BankAccount account(12345678); account.credit(5000);
Note how the internal workings of the class are hidden, the code is easier on the eye, the code handling the internals of the class takes care of the details. This is how encapsulation helps. The class encapsulates the details for us.
At the bank, we offer different types of account for our customers. Current Account and Savings Account for example. They are similar - they are both types of bank account, but also different: a Savings Account will accrue more interest than a Current Account.
With OO, we can derive from our BankAccount class two new classes, CurrentAccount and SavingsAccount. Both these new account types share the same BankAccount characteristics, but each of the new classes can be specialized to suit.
CurrentAccount c_account; SavingsAccount s_account; c_account.accrueInterest(); s_account.accrueInterest();
The accrueInterest operation can be applied to each of the two new classes. The difference is that the c_account account earns 0.1% interest and the s_account account earns 15% interest. (We love savers). This demonstrates the polymorphic and inheritance features of OO languages. We have cloned the BankAccount class, and derived two new classes which inherit their character from thier parent class, but also have their own little personalities. Ahh, how sweet. And the same operation (accrueInterest) has more than one form or, as we know it, it is polymorphic. It can accrue a 0.1% pittance of interest, or a generous 15%, depending on the type of the BankAccount object in use.