Principles of Object Oriented Programming

Hello students, welcome to Kwickprep. Apps like a UPI wallet have lakhs of lines of code. How do programmers keep so much code under control? They use object oriented programming. Today we will solve one problem in two styles, and learn the four big ideas that make large programs manageable.

There are two main styles of writing a program. In procedure oriented programming, the program is a set of functions, and a function is a named block of steps. The data sits outside, in separate variables, and we pass it to each function. In object oriented programming, or O O P, the program is built from objects. An object keeps its own data and its own actions together, in one place.

Here is one problem: Riya has five hundred rupees in her wallet and adds two hundred. First, the procedure style. The word def defines a function called add. Return sends the answer back. The balance lives outside, so we must pass it in and store the result again. It prints seven hundred.

Now the same problem in object style. A class is a design for objects, and here the class is Wallet. The setup method, init, runs when a wallet is made and stores its balance. Self means this object itself. Plus equals adds to the value already there. Riya's wallet now carries its own balance, so we simply say riya dot add. It prints seven hundred again.

Both programs print seven hundred, so what is the difference? Procedure style is built around functions, and object style is built around objects. In procedure style the data lives in loose variables, but in object style it lives inside the object. With one hundred wallets, you juggle one hundred loose variables, instead of one hundred neat objects. And protecting the data is hard in procedure style, but easier with objects.

An object models a real thing from the world, called an entity. Every entity has state, which is the data it knows, and behaviour, which is what it can do. A mobile phone knows its battery level and balance, and it can call and charge. A student has a name and marks, and can study and give an exam. A train has a number and free seats, and it can run and book a seat.

Here is the phone as a Python object. Its state is the battery, stored inside the object. Its behaviour is the charge method, and a method is a function that belongs to an object. We make a phone with twenty percent battery, called mine. Calling charge changes its own state to one hundred. So it prints one hundred.

O O P rests on four big ideas, called pillars, and one UPI payment app shows all four. Abstraction means showing only what matters, so you tap Pay without seeing the bank's steps. Encapsulation means wrapping data inside an object and guarding it, like your hidden pin. Inheritance means a new class reuses a parent class, so every payment type sends a receipt. Polymorphism means one name with many forms, so pay works differently for UPI and for a card.

Python has no private keyword like some other languages. Instead, two underscores before a name hide it, and Python quietly changes that name inside the class. So reading acc dot underscore underscore pin from outside gives an attribute error. The safe way in is the check method, which answers True or False. Double equals compares, and one two three four is wrong, so False. Pause and predict. What prints for check of the number four eight two one, without quotes? Also False, because a number is never equal to text.

Payment is the parent class, and it has a receipt method. We write class UPI, with Payment in brackets, to make a child class. The word pass means the child adds nothing new yet. Still, the UPI object can call receipt, because it inherits it from its parent. So it prints Receipt sent, and we never wrote that code twice.

Both classes have a method with the same name, pay. We call pay on a UPI object, then on a Card object. The line is the same each time: dot pay. But the UPI object asks you to scan the QR code, and the card object asks you to tap. One name, many forms. That is polymorphism.

Abstraction ties the other ideas together. The shopkeeper's app just calls pay, and never sees the steps with the bank. The bank steps can change inside the class, and the app keeps working. So one team can build the payment class while another builds the screens.

So why do large programs use O O P? Each class is a small piece that does one job, so the program is easy to read. Inheritance lets us reuse code instead of copying it. Encapsulation keeps important data, like a pin, safe from mistakes. A bug in payments means fixing one class, not the whole app. And the code looks like the real world, so new programmers understand it quickly.

Let us revise what we learned today. Procedure style uses functions, with the data kept separately. Object style builds objects that hold their state and behaviour together. The four pillars are abstraction, encapsulation, inheritance and polymorphism. Together they split a big program into small, safe and reusable parts.