Skip to content
Zeni Study
Share
Explore

Day 4 : Bank account and notification system.

Today we cover Inheritance, but in a strict, interview-realistic way:
❌ No design pattern talk
❌ No theory lectures
❌ No abstraction for abstraction’s sake
✅ Inheritance only when the problem forces it
✅ Heavy implementation with clear rules
⁠

🟢 Day 4 — Inheritance & Method Overriding (Machine Coding Style)

🎯 Day 4 Objective

By the end of Day 4, the candidate should be able to:
Implement inheritance when required
Share common data and behavior using a base class
Override methods correctly
Use super() properly
Handle different rules for different subclasses
Pass machine-coding tests involving parent–child classes
Today is about reusing structure, not logic guessing.
⁠

1️⃣ Teaching Script — What to Say

Start with This Reality

“Most of the time, you do NOT need inheritance. But when the problem says ‘There are multiple types of X’, you almost always do.”
Examples from interviews:
Employee → FullTime / PartTime
Account → Savings / Current
Vehicle → Bike / Car
Inheritance exists to share common structure, not to look smart.
⁠

2️⃣ Core Idea of Inheritance (Only What’s Needed)

A child class IS A parent class, but with extra or different behavior.
Child inherits:
Variables
Methods
Child can:
Override methods
Add new behavior
⁠

3️⃣ Small Code to Understand (Minimal, Clear)

Example — Employee Base Class

class Employee:
def __init__(self, emp_id: int, salary: int):
self.emp_id = emp_id
self.salary = salary

def calculate_pay(self) -> int:
return self.salary

Child Class

class PartTimeEmployee(Employee):
def calculate_pay(self) -> int:
return self.salary // 2

Key Observations

Same method name
Different behavior
Caller does NOT need to know type
🧠 Machine coding tests whether you override correctly, not creatively.
⁠

4️⃣ Mandatory Warm-up Practice

Task

Implement the following:
Base class: Shape
- area() → int

Child classes:
- Square (side)
- Rectangle (length, width)
Rules:
Use inheritance
Override area()
No prints, only return
👉 This ensures candidate understands override mechanics.
⁠

5️⃣ Machine Coding Rules (Day 4 Rules)

Use inheritance only where specified
Do NOT duplicate common fields
Call super().__init__() when required
Override only the required methods
Keep logic exactly as specified
⁠

6️⃣ Main Problem 1 — Account Types (Classic Interview Question)

Problem Statement

You are implementing a banking system with different account types.
All accounts have:
account number
balance
But withdrawal rules differ.
⁠

Class Definitions (DO NOT MODIFY)

class Account:
def __init__(self, account_number: str, balance: int):
pass

def withdraw(self, amount: int) -> bool:
pass

def get_balance(self) -> int:
pass


class SavingsAccount(Account):
def withdraw(self, amount: int) -> bool:
pass


class CurrentAccount(Account):
def withdraw(self, amount: int) -> bool:
pass
⁠

Requirements (Very Strict)

Account (Base Class)
Stores account_number and balance
get_balance() returns balance
withdraw() in base class should:
Always return False
(Base class should not allow withdrawal)
⁠
SavingsAccount
Cannot withdraw more than balance
If amount <= 0 → return False
If amount > balance → return False
Else:
Deduct amount
Return True
⁠
CurrentAccount
Can overdraft up to -1000
If amount <= 0 → return False
If balance - amount < -1000 → return False
Else:
Deduct amount
Return True
⁠

Example

sa = SavingsAccount("S1", 500)
sa.withdraw(600) # False
sa.withdraw(200) # True

ca = CurrentAccount("C1", 500)
ca.withdraw(1200) # True (balance becomes -700)
ca.withdraw(500) # False (would exceed overdraft)
⁠

7️⃣ Main Problem 2 — Notification System

Problem Statement

You are implementing a notification system.
Different notification types behave differently, but share a common interface.
⁠

Class Definitions (DO NOT MODIFY)

class Notification:
def send(self, message: str) -> bool:
pass


Gallery
 
Want to print your doc?
This is not the way.
Try clicking the ··· in the right corner or using a keyboard shortcut (
CtrlP
) instead.