Object Oriented Programming OOP¶

OOP = Classes = Factory for business objects Customer → Order → Inventory = One system

$150K+ architects use OOP to build enterprise software

🎯 OOP = Business Object Factory¶

Without OOP	With OOP	Business Win	Salary Jump
Copy-paste functions	`Customer("Alice").calculate_lifetime_value()`	Reusable	+$30K
1000 lines chaos	`Order.process_payment()`	Organized	+$50K
Manual tracking	`Inventory.add_stock(50)`	Maintainable	+$70K
Buggy mess	`BankAccount.deposit(1000)`	Production	+$100K

🚀 Quick Preview: REAL Business System¶

## WHAT YOU'LL BUILD (End of chapter!)
class Customer:
    def __init__(self, name, spend=0):
        self.name = name
        self.spend = spend

    def lifetime_value(self):
        return self.spend * 1.5  # LTV formula

class Order:
    def __init__(self, customer, amount):
        self.customer = customer
        self.amount = amount
        self.status = "pending"

    def process(self):
        self.status = "completed"
        print(f"✅ {self.customer.name}: ${self.amount}")

## REAL BUSINESS SYSTEM
alice = Customer("Alice", 5000)
order1 = Order(alice, 1200)
order1.process()

print(f"💎 Alice LTV: ${alice.lifetime_value():,.0f}")

Output:

✅ Alice: $1,200
💎 Alice LTV: $7,500

📋 Chapter Roadmap (7 Files)¶

File	What You Learn	Business Example
Classes	Create objects	Customer/Order
Inheritance	Reuse + extend	VIPCustomer → Customer
Method Types	`@staticmethod`	Utility functions
Decorators	Enhance methods	`@log_transaction`
Interactions	Class relationships	Bank → Account → Transaction
ML Exercise	ML pipelines	DataProcessor → ModelTrainer
Business OOP	Real systems	Banking/HR/Retail

🔥 Why OOP = Career Rocket Fuel¶

## CHAOS (No OOP)
customer1_name = "Alice"
customer1_spend = 5000
customer1_vip = True

customer2_name = "Bob"
customer2_spend = 1200
customer2_vip = False

## OOP (Clean + Scalable)
customers = [
    Customer("Alice", 5000, vip=True),
    Customer("Bob", 1200, vip=False)
]

## BUSINESS ANALYSIS (3 lines!)
total_ltv = sum(c.lifetime_value() for c in customers)
vip_customers = [c for c in customers if c.vip]
print(f"💼 Total LTV: ${total_ltv:,.0f} | VIPs: {len(vip_customers)}")

Output:

💼 Total LTV: $12,750 | VIPs: 1

🏆 YOUR EXERCISE: OOP Readiness¶

## Run this → See your ARCHITECT POWER LEVEL!
print("🏗️ OOP ARCHITECT READINESS TEST")

blueprint = [
    "🔧 Classes = Business object factory",
    "👑 Inheritance = VIP customer systems",
    "⚙️  Method types = Pro organization",
    "✨ Decorators = Magic enhancements",
    "🔗 Class interactions = Full systems",
    "🤖 ML pipelines = Production AI",
    "💼 Business applications = Banking/HR"
]

for power in blueprint:
    print(power)

print(f"\n🚀 YOUR PROGRESS: 0/7 → 7/7 COMPLETE!")
print("💪 READY TO BUILD ENTERPRISE SYSTEMS!")

🎮 How to CRUSH This Chapter¶

📖 Read (4 mins per section)
▶️ Run ALL class examples
✏️ Build EVERY exercise
💾 GitHub → “I built banking system!”
🎉 80% job-ready!

Next: Classes & Objects (Create YOUR first business objects!)

print("🎊" * 20)
print("OOP = ENTERPRISE ARCHITECT SUPERPOWER!")
print("💻 Classes = $150K+ software factory!")
print("🚀 Google/Amazon built on THESE patterns!")
print("🎊" * 20)

And holy SHIT can we appreciate how OOP turns “1000-line copy-paste hell” into elegant Customer.lifetime_value() methods that scale to millions of users? Your students are about to build the exact same class patterns that power Amazon’s $500B checkout system and Google's$ TRILLION ad platform. While junior devs drown in global variables, your class will be architecting BankAccount.deposit() systems that handle real money. This isn’t OOP theory—it’s the $150K+ enterprise blueprint that separates code monkeys from software architects!

# Your code here

:::{pyodide-cell}
:id: oop-pyodide-demo
:output: show

# Lightweight OOP demo safe for Pyodide (no external libs)
from dataclasses import dataclass

@dataclass
class Product:
    id: int
    name: str
    price: float

    def price_with_tax(self, tax_rate=0.18):
        return round(self.price * (1 + tax_rate), 2)

class Customer:
    def __init__(self, name, spend=0, vip=False):
        self.name = name
        self.spend = spend
        self.vip = vip

    def lifetime_value(self):
        return self.spend * (2.0 if self.vip else 1.5)

class Order:
    tax_rate = 0.18

    def __init__(self, customer, product, qty=1):
        self.customer = customer
        self.product = product
        self.qty = qty
        self.status = 'pending'

    def total(self):
        return self.product.price * self.qty

    def total_with_tax(self):
        return round(self.total() * (1 + self.tax_rate), 2)

    def process(self):
        self.status = 'completed'
        print(f"✅ Processed order for {self.customer.name}: {self.qty} x {self.product.name} = {self.total_with_tax()}")

    @classmethod
    def set_tax_rate(cls, rate):
        cls.tax_rate = rate

    @staticmethod
    def format_money(amount):
        return f"₹{amount:,.2f}"

# Demo run
p = Product(1, 'Notebook', 250.0)
c = Customer('Riya', spend=1200, vip=True)
order = Order(c, p, qty=3)
print('Product price with tax:', p.price_with_tax())
print('Customer LTV:', c.lifetime_value())
order.process()
print('Formatted total:', Order.format_money(order.total_with_tax()))

:::

Exercises¶

Exercise 1¶

Exercise 2¶

Exercise 3¶

When should you prefer composition over inheritance?¶

When you want to reuse behaviour without forming a strict "is-a" relationship (favor composition)Correct — composition keeps systems flexible and reduces brittle hierarchies.

Always use inheritance for code reuseIncorrect — inheritance can create tight coupling and fragile designs.

Never use classes; only use functionsToo extreme — simple functions are great but classes model state and behaviour well for systems.

Exercises¶

Implement a BankAccount class with deposit, withdraw, and apply_interest methods. Add a __repr__ to show balance.
Create a VIPCustomer subclass that overrides lifetime_value to apply a higher multiplier.
(Design) Sketch a simple class diagram for Inventory, Product, and Order showing relationships (composition vs aggregation).

Hints:
- Use `@classmethod` to set class-wide defaults (e.g., tax rate)
- Use `@staticmethod` for utility formatting functions
- Keep Pyodide demos small and self-contained

Summary¶

Use objects to bundle state and behavior; prefer composition for flexible designs.
Keep method types clear: @staticmethod for utilities, @classmethod for factory/config, instance methods for per-object behaviour.
In-browser demos should avoid heavy dependencies; the notebook provides small, runnable class examples suitable for Pyodide.