Skip to main content

Documentation Index

Fetch the complete documentation index at: https://resources.devweekends.com/llms.txt

Use this file to discover all available pages before exploring further.

Who is this for? Complete beginners! If you’ve never heard of OOP or find it confusing, you’re in the right place. We’ll use real-world examples that anyone can understand!

​
🧱 Think of Code Like LEGO

Imagine you’re building with LEGO blocks. Each block is a piece that can connect with other blocks to build something amazing - like a castle, a spaceship, or a city! Object-Oriented Programming (OOP) works the same way:
  • Instead of LEGO blocks, we have Objects
  • Objects are like little machines that can store information and do things
  • We connect objects together to build amazing software!

Without OOP

Code is like a long grocery list - just instructions one after another. Hard to organize and find things!

With OOP

Code is organized into objects - like having labeled boxes for everything. Easy to find and change!

​
🐕 Your First Object: A Dog!

Let’s create a simple object in our minds - a Dog. What does every dog have?
  • A name (like “Buddy”)
  • A color (like “brown”)
  • An age (like 3 years)
What can every dog do?
  • Bark (“Woof woof!”)
  • Eat (munch munch)
  • Sleep (zzz…)
In programming, we call:
  • Things a dog has = Attributes (or Properties)
  • Things a dog can do = Methods (or Actions)
# This is how we create a Dog "blueprint" in Python
class Dog:
    # Things a dog HAS (attributes)
    def __init__(self, name, color, age):
        self.name = name
        self.color = color
        self.age = age
    
    # Things a dog CAN DO (methods)
    def bark(self):
        print(f"{self.name} says: Woof woof! 🐕")
    
    def eat(self):
        print(f"{self.name} is eating... yum!")
    
    def sleep(self):
        print(f"{self.name} is sleeping... zzz 😴")

# Now let's CREATE actual dogs from our blueprint!
buddy = Dog("Buddy", "brown", 3)
max = Dog("Max", "black", 5)

# Let's make them do things!
buddy.bark()   # Output: Buddy says: Woof woof!
max.eat()      # Output: Max is eating... yum!
Key Insight: A class is like a cookie cutter - it’s a template. An object is like the actual cookie - it’s the real thing made from the template!

​
The Four Superpowers of OOP

OOP gives you four amazing superpowers (we call them “pillars”):

1. Encapsulation

Hide the messy stuff inside a boxLike a TV remote - you just press buttons, you don’t need to know how circuits work inside!

2. Inheritance

Pass down abilities from parent to childLike how you might have your mom’s eyes or your dad’s height - children inherit from parents!

3. Polymorphism

Same action, different results“Speak” means different things to a dog (bark), cat (meow), and cow (moo)!

4. Abstraction

Show only what’s importantA car’s dashboard shows speed, not engine chemistry. Hide complexity, show simplicity!

​
Why Does Everyone Use OOP?

Almost every app you use is built with OOP:
AppObjects You’d Find Inside
Video GamesPlayer, Enemy, Weapon, Level, Score
InstagramUser, Post, Comment, Like, Story
AmazonProduct, Cart, Order, Customer, Review
SpotifySong, Playlist, Artist, Album, User
UberDriver, Rider, Trip, Payment, Location
Why?
  1. Easy to understand - Objects match how we think in real life
  2. Easy to change - Fix one object without breaking others
  3. Easy to reuse - Use the same object in different projects
  4. Easy to team work - Different people work on different objects
Think about it this way: A city is made of buildings, roads, and services — not one giant blob. Each building has a purpose (hospital, school, store), its own internal rules, and a public entrance. OOP organizes code the same way. Without it, large codebases become like a city with no zoning laws — everything is everywhere and nothing is maintainable.

​
Try It Yourself!

Let’s make sure you understand before moving on:
A class is like a blueprint or template for creating objects.Think of it like:
  • A cookie cutter (class) → makes cookies (objects)
  • A car factory blueprint (class) → makes actual cars (objects)
  • A dog breed description (class) → describes actual dogs (objects)
  • Attributes = What something HAS (data, properties)
    • Example: A car HAS a color, speed, brand
  • Methods = What something CAN DO (actions, behaviors)
    • Example: A car CAN start, stop, accelerate
Objects you might need:
  • Student (has: name, age, grade | can: study, take exam, join club)
  • Teacher (has: name, subject, salary | can: teach, grade papers, assign homework)
  • Classroom (has: room number, capacity | can: host class, be booked)
  • Course (has: name, credits | can: enroll student, generate report)

​
What’s Next?

Now that you understand the basics, let’s dive deep into each superpower:

Encapsulation

Learn to protect your data and hide complexity

Start Encapsulation →

Inheritance

Learn to create families of related objects

Start Inheritance →

Polymorphism

Learn to write flexible, reusable code

Start Polymorphism →

Abstraction

Learn to simplify complex systems

Start Abstraction →

Learning Tip: Don’t rush! Take your time with each concept. Try the code examples yourself. The best programmers learn by doing, not just reading!

​
Interview Insight

Why interviewers ask about OOP: They are not testing whether you can recite definitions. They want to see if you can decompose a problem into objects with clear responsibilities. When asked “design a parking lot system,” the first thing they evaluate is whether you identify the right objects (ParkingLot, Level, Spot, Vehicle, Ticket) and assign each object sensible attributes and behaviors. A senior engineer would say: “OOP is a tool for managing complexity — the four pillars are not rules to memorize, they are strategies for keeping large systems understandable.” Start every LLD answer by identifying nouns (objects) and verbs (methods), and you are already ahead of most candidates.

​
Interview Deep-Dive

Strong Answer:
  • Non-technical explanation: A class is a blueprint, like the architectural plan for a house. An object is an actual house built from that blueprint. You can build many houses from the same plan, but each house has its own address, paint color, and residents. Changing the furniture in one house does not affect the others.
  • Senior engineer explanation: A class defines a type — it specifies the memory layout (attributes), the behavioral contract (methods), and the access control (public/private). An object is a runtime instance allocated on the heap with its own state. The class is a compile-time construct; the object is a runtime construct. In Python, classes themselves are also objects (instances of the metaclass type), which enables metaprogramming patterns like Singleton metaclasses and dynamic class creation.
  • The practical interview implication: when you identify “a Dog” in a problem statement, you are identifying a class. When you say “Buddy the golden retriever with age 3,” you are identifying an object. The interviewer wants to see that you think about both the type hierarchy (design level) and the runtime instances (implementation level).
Follow-up: What is the relationship between classes and types in Python, and why does it matter for LLD?In Python, every class is a type and every object has a type. But Python also supports duck typing: if an object has a quack() method, it can be used anywhere a duck is expected, regardless of its actual class. This means your LLD designs in Python should rely on interfaces (ABC) or protocols (Protocol from typing) rather than concrete class hierarchies for polymorphic behavior. In an interview, this is why you define abstract base classes for your design contracts rather than relying solely on inheritance.
Strong Answer:
  • Step 1: Extract nouns from the requirements. “School management system” gives us: School, Student, Teacher, Course, Classroom, Grade, Schedule, Enrollment. Each noun is a candidate class.
  • Step 2: Filter nouns. Some nouns are attributes rather than classes. “Name” is an attribute of Student, not its own class. “Grade” could be a class (if it has behavior) or an enum (if it is just a label). I ask: does this noun have both data AND behavior? If yes, it is a class. If it is just data, it is an attribute.
  • Step 3: Extract verbs. “Enroll student in course,” “assign teacher to course,” “generate report card,” “schedule classes.” Each verb becomes a candidate method, and the subject-object relationship tells you which class owns the method. “Enroll student” means Course or EnrollmentService has an enroll(student) method.
  • Step 4: Identify relationships. Student enrolls in Course (many-to-many, resolved by an Enrollment class). Teacher teaches Course (one-to-many). Course is held in Classroom (one-to-one per time slot). These relationships become association, composition, or aggregation lines on the class diagram.
  • Step 5: Validate with use cases. “A student enrolls in a course” — trace through the classes: Student calls EnrollmentService.enroll(), which checks Course.hasCapacity(), creates an Enrollment object, and notifies the Student. If the trace breaks, the design is missing a class or method.
Follow-up: How do you decide whether Grade should be a class, an enum, or just a string attribute?If Grade has behavior (calculate GPA, check if passing, determine honor roll eligibility), it should be a class or at least a rich enum with methods. If Grade is purely a label (A, B, C, D, F) with no associated logic, a simple enum or string suffices. In interviews, I default to making it a class if the problem mentions any grading rules, because it demonstrates that I think about where behavior lives rather than scattering grade-related logic across multiple classes.
Strong Answer:
  • OOP dominates LLD interviews because it provides a shared vocabulary for discussing design. Classes, interfaces, inheritance, and composition map naturally to how interviewers and candidates communicate about system structure. When someone says “Vehicle is an abstract class with Car and Truck subclasses,” everyone pictures the same hierarchy.
  • OOP is excellent for modeling entities with state and behavior: a BankAccount that has a balance and can deposit/withdraw, a Game with players and moves, a ParkingLot with floors and spots. It naturally handles the “nouns and verbs” decomposition that LLD problems require.
  • However, OOP has real limitations. First, it can lead to over-modeling: creating class hierarchies for things that are better represented as data transformations (functional programming) or simple dictionaries. Not every concept needs a class. Second, deep inheritance hierarchies create fragile coupling. Third, OOP can obscure the flow of data through a system — you have to chase method calls across many classes to understand what happens during a request.
  • In practice, the best LLD designs use OOP for entity modeling and structural organization, but borrow from functional programming for stateless transformations (pricing calculations, validation pipelines) and from event-driven architecture for decoupled communication (Observer pattern, message queues).
Follow-up: If OOP is not always the best paradigm, why not use functional programming for LLD interviews?Some companies do accept FP-style answers, but the challenge is communication. LLD interviews are fundamentally about communicating structure: class diagrams, relationships, and design patterns. FP does not have an equivalent universally understood visual vocabulary. A class diagram with six boxes and arrows conveys the architecture in seconds. Describing the same system as a pipeline of pure functions and immutable data transformations takes more explanation. OOP is the lingua franca of LLD interviews, even if the actual production code uses a mix of paradigms.