Introduction
Object-oriented programming, OOP, is a way of structuring code around objects rather than around a sequence of instructions. An object bundles together data, called fields or attributes, with the functions that operate on that data, called methods. Instead of writing loose functions that pass raw data back and forth, OOP groups related data and behavior into a single unit, which mirrors how real-world things are usually described: a thing that has properties and can do things.
Cricket analogy: A cricket team doesn't track a player's batting average, fitness score, and bowling speed as three separate spreadsheets passed between departments; the player's own profile bundles those stats with the actions they can perform, which is exactly the bundling of data and behavior that a class provides in object-oriented programming.
Explanation
The blueprint for creating objects is called a class, and an individual instance created from that blueprint is called an object. A class defines what fields an object will have and what methods it can run, but the class itself is not a specific thing — it's the template. Encapsulation is the OOP principle of hiding an object's internal details behind its methods, so other code interacts with the object through a defined interface rather than reaching in and modifying its fields directly. This keeps the internal representation free to change without breaking code that depends on the object.
Cricket analogy: A national board's official player-registration template defines what fields every registered player record will have, such as name and batting hand, but the template itself isn't a player; the actual registered player is the object, and the board only lets other departments query a player's status through official channels rather than editing the raw file, mirroring a class defining structure and encapsulation hiding internals behind an interface.
Inheritance lets one class reuse and extend the fields and methods of another, so a more specific class can build on a general one without duplicating its code. Polymorphism means that different classes can respond to the same method call in their own way, letting code treat objects of different specific types uniformly through a shared method name while each type still does the right thing for itself.
Cricket analogy: A T20 franchise's youth-academy contract template can be built on top of the base player-contract template, adding academy-specific clauses without rewriting the whole document, which is inheritance; and calling 'perform()' on a batter versus a bowler triggers a different specific action for each even though the same word is used, which is polymorphism.
class Account:
def __init__(self, owner, balance=0):
self._owner = owner
self._balance = balance
def deposit(self, amount):
self._balance += amount
def withdraw(self, amount):
if amount > self._balance:
raise ValueError("Insufficient funds")
self._balance -= amount
def get_balance(self):
return self._balance
class SavingsAccount(Account):
def __init__(self, owner, balance=0, rate=0.02):
super().__init__(owner, balance)
self._rate = rate
def apply_interest(self):
self._balance += self._balance * self._rate
Abstraction is closely related to encapsulation: it means exposing only what a caller needs to know (deposit, withdraw, get_balance) while hiding how the balance is actually stored or validated internally.
Example
Consider a simple banking example: the Account class defines fields for owner and balance, plus methods deposit, withdraw, and get_balance. A SavingsAccount can inherit from Account and add its own apply_interest method, reusing all the deposit and withdraw logic without rewriting it. Any code that calls get_balance on either type of account gets a correct answer without needing to know which specific subclass it is dealing with.
Cricket analogy: A generic PlayerContract class defines fields for name and match fee plus methods to sign and renew, and a SpecialistBowlerContract can inherit from it and add a wicket-bonus method without rewriting the signing logic, so any department calling getFee on either contract type gets a correct number without caring which subclass it is.
Analysis
A common beginner mistake is overusing inheritance to model every relationship, creating deep and fragile class hierarchies. When a relationship is really 'has a capability' rather than 'is a specialized kind of', composition (an object holding a reference to another object) is usually a more flexible choice than forcing an inheritance chain.
Key Takeaways
- A class is a blueprint; an object is a specific instance created from that blueprint.
- Encapsulation hides an object's internal fields behind methods, so callers interact through a defined interface.
- Inheritance lets a class reuse and extend another class's fields and methods without duplicating code.
- Polymorphism lets different classes respond to the same method call in their own type-specific way.
- Composition is often a more flexible alternative to inheritance when the relationship is 'has a capability' rather than 'is a kind of'.
Practice what you learned
1. In OOP, what is the relationship between a class and an object?
2. What is encapsulation primarily used for?
3. Which OOP feature allows a subclass to reuse and extend a superclass's fields and methods?
4. What does polymorphism allow in an OOP program?
5. Why might composition be preferred over inheritance for a given relationship?
Was this page helpful?
You May Also Like
What Is an Algorithm
An explanation of what an algorithm is, why correctness and efficiency both matter, and how Big O notation describes growth.
What Is an API
An overview of application programming interfaces, how they define a contract between systems, and how REST APIs use HTTP.
What Is JSON
An introduction to JSON's syntax and data types, and why it became the standard format for exchanging structured data between systems.
Reading Documentation
A practical guide to reading technical documentation efficiently, covering reference docs, signatures, examples, and changelogs.
Related Reading
Related Study Notes in Programming
Browse all study notesApache Spark Study Notes
Programming · 30 topics
ProgrammingApache Flink Study Notes
Programming · 30 topics
ProgrammingHadoop Study Notes
Programming · 30 topics
ProgrammingSnowflake Study Notes
Programming · 30 topics
ProgrammingApache Airflow Study Notes
Programming · 30 topics
Programmingdbt (Data Build Tool) Study Notes
Programming · 30 topics