OOP - lesson 3 | HackIndia Skills

Key point

One idea

Encapsulation means your object protects its own rules. Other code should ask the object to do a valid action, not reach inside and edit its state.

Why it matters

In a hackathon repo, recruiters do not expect a huge design. They look for code where bugs are harder to create.

If anyone can change every field, your class is just a loose data bag. A small method like markPaid() or assignDriver() can check rules before state changes.

Example

Bad shape

This looks simple, but any part of the app can put the order into a wrong state. You can mark it paid with zero amount. You can set any random status string.

class FoodOrder:
    def __init__(self, order_id, total_rupees):
        self.order_id = order_id
        self.total_rupees = total_rupees
        self.status = "CREATED"
        self.paid = False

order = FoodOrder("ORD-17", 0)
order.paid = True
order.status = "DONE_DONE"

Example

Better shape

Keep fields private by convention, then expose methods for real actions. This version is still small. No framework. No extra pattern.

class FoodOrder:
    VALID_STATUSES = {"CREATED", "PAID", "CANCELLED"}

    def __init__(self, order_id, total_rupees):
        if total_rupees <= 0:
            raise ValueError("Order total must be more than 0")
        self._order_id = order_id
        self._total_rupees = total_rupees
        self._status = "CREATED"

    def mark_paid(self):
        if self._status == "CANCELLED":
            raise ValueError("Cancelled order cannot be paid")
        self._status = "PAID"

    def cancel(self):
        if self._status == "PAID":
            raise ValueError("Paid order cannot be cancelled here")
        self._status = "CANCELLED"

    def summary(self):
        return {
            "order_id": self._order_id,
            "total_rupees": self._total_rupees,
            "status": self._status
        }

order = FoodOrder("ORD-17", 199)
order.mark_paid()
print(order.summary())

Your to-do

Encapsulate a class

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

List the state your feature stores, like amount, status, owner, or due date.
Mark which fields should not be changed directly after creation.
Write methods for real actions users take, like pay, cancel, approve, join, or submit.
Put validation inside those methods, close to the state they protect.
Return a simple summary when outside code only needs to display data.

0 of 5 done

Common mistake

Getter setter trap

Do not create getStatus() and setStatus() for every field by habit. That often gives public access with extra typing.

Use a setter only when outside code is allowed to change that value directly. If there is a rule, name the method after the action and enforce the rule there.

Tip

Use AI safely

You can ask ChatGPT or Gemini: “Given this class, which fields should be private and what methods should change them?” Then check the answer yourself.

Reject suggestions that add abstract factories, managers, or service layers for a tiny feature. For this lesson, one clear class with protected rules is enough.