OOP - lesson 4 | HackIndia Skills

OOP - lesson 4 | HackIndia Skills | HackIndia

Example

Inheritance version

This looks fine at first. But every new payment type can force changes in the parent class. The parent starts knowing too much.

class Order:
    def __init__(self, amount):
        self.amount = amount

    def pay_by_upi(self, upi_id):
        print(f"Paid ₹{self.amount} using UPI: {upi_id}")

    def pay_by_card(self, card_last4):
        print(f"Paid ₹{self.amount} using card ending {card_last4}")


class FoodOrder(Order):
    def __init__(self, amount, restaurant_name):
        super().__init__(amount)
        self.restaurant_name = restaurant_name

Example

Composition version

Here, FoodOrder has a payment method. It does not inherit payment behaviour. It uses another object to do that job.

This is easier to test. You can test FoodOrder separately from UPI payments.

class UpiPayment:
    def __init__(self, upi_id):
        self.upi_id = upi_id

    def pay(self, amount):
        return f"Paid ₹{amount} using UPI: {self.upi_id}"


class FoodOrder:
    def __init__(self, amount, restaurant_name, payment_method):
        self.amount = amount
        self.restaurant_name = restaurant_name
        self.payment_method = payment_method

    def checkout(self):
        return self.payment_method.pay(self.amount)


payment = UpiPayment("student@oksbi")
order = FoodOrder(249, "Campus Canteen", payment)
print(order.checkout())

Composition before inheritance

One idea

Why this matters

Common wrong turn

Inheritance version

Composition version

How to decide

Use AI carefully

Do this now

Quick check