Bird
Raised Fist0
LLDsystem_design~7 mins

Class responsibilities and behavior in LLD - System Design Guide

Choose your learning style10 modes available
Problem Statement
When classes have unclear or mixed responsibilities, the code becomes hard to understand, maintain, and extend. This often leads to bugs and duplicated logic because behaviors are scattered or overloaded in the wrong places.
Solution
Assign each class a clear responsibility focused on a single purpose. Define behaviors (methods) that belong naturally to that responsibility. This keeps classes simple, cohesive, and easier to manage, making the system more robust and adaptable.
Architecture
User Class
───────────────
↓
Payment Class
Payment Class

This diagram shows three classes each with focused responsibilities and behaviors: User handles login/logout, Order manages items and totals, Payment processes payments.

Trade-offs
✓ Pros
→
Improves code readability by grouping related data and behavior.
→
Makes testing easier by isolating functionality.
→
Facilitates future changes by limiting impact to specific classes.
→
Encourages reuse of well-defined behaviors.
✗ Cons
→
Requires upfront design effort to define clear responsibilities.
→
May lead to more classes, increasing the number of components to manage.
→
Improper responsibility assignment can still cause tight coupling.
Always use when designing object-oriented systems, especially when classes grow beyond a few methods or when multiple developers work on the codebase.
Not applicable for very small scripts or procedural code where classes are unnecessary overhead.
Real World Examples
Amazon
Separates order processing, user management, and payment handling into distinct classes to keep the system modular and maintainable.
Uber
Uses clear class responsibilities to manage drivers, riders, and trip behaviors separately, enabling rapid feature development.
Shopify
Defines classes with focused responsibilities for products, carts, and checkout to simplify complex e-commerce workflows.
Code Example
The before code mixes user data, login behavior, and order total calculation in one class, making it hard to maintain. The after code splits responsibilities: User handles login, Order manages items and totals, and UserOrders manages multiple orders. This separation improves clarity and maintainability.
LLD
### Before: Mixed responsibilities in one class
class User:
    def __init__(self, name, email):
        self.name = name
        self.email = email
        self.orders = []

    def login(self):
        print(f"{self.name} logged in")

    def add_order(self, order):
        self.orders.append(order)

    def calculate_total_spent(self):
        total = 0
        for order in self.orders:
            total += sum(item['price'] for item in order['items'])
        return total


### After: Clear responsibilities split into classes
class User:
    def __init__(self, name, email):
        self.name = name
        self.email = email

    def login(self):
        print(f"{self.name} logged in")

class Order:
    def __init__(self, order_id):
        self.order_id = order_id
        self.items = []

    def add_item(self, item):
        self.items.append(item)

    def calculate_total(self):
        return sum(item['price'] for item in self.items)

class UserOrders:
    def __init__(self):
        self.orders = []

    def add_order(self, order):
        self.orders.append(order)

    def calculate_total_spent(self):
        return sum(order.calculate_total() for order in self.orders)
OutputSuccess
Alternatives
Procedural Programming
Focuses on functions and data separately without bundling behavior with data in classes.
Use when: Use when the problem is simple or performance-critical and object-oriented overhead is unnecessary.
Anemic Domain Model
Separates data and behavior, placing logic outside classes, often leading to less cohesive design.
Use when: Sometimes chosen for simple CRUD applications but generally discouraged for complex domains.
Summary
Assign each class a clear, focused responsibility to keep code simple and maintainable.
Define behaviors that naturally belong to the class’s responsibility to encapsulate logic.
Clear class responsibilities improve readability, testing, and future changes.

Practice

(1/5)
1. Which of the following best describes the main responsibility of a class in low-level design?
easy
A. To store only data without any methods
B. To group related data and behaviors together
C. To execute the entire program logic
D. To act as a database table

Solution

  1. Step 1: Understand class purpose

    A class is designed to bundle data (attributes) and behaviors (methods) that operate on that data.
  2. Step 2: Evaluate options

    To group related data and behaviors together correctly states this bundling. Options B, C, and D misunderstand class roles.
  3. Final Answer:

    To group related data and behaviors together -> Option B
  4. Quick Check:

    Class responsibility = Group data and behavior [OK]
Hint: Classes combine data and methods logically [OK]
Common Mistakes:
  • Thinking classes only hold data
  • Confusing classes with entire program logic
  • Assuming classes are database tables
2. Which of the following is the correct way to define a method inside a class in Python?
easy
A. def methodName():
B. function methodName():
C. method methodName(self):
D. def methodName(self):

Solution

  1. Step 1: Recall Python method syntax

    In Python, methods inside classes must include 'self' as the first parameter to access instance data.
  2. Step 2: Check options

    def methodName(self): uses 'def' and includes 'self', which is correct. Options B and C use incorrect keywords. def methodName(): misses 'self'.
  3. Final Answer:

    def methodName(self): -> Option D
  4. Quick Check:

    Python method syntax = def methodName(self): [OK]
Hint: Remember 'self' is first parameter in Python methods [OK]
Common Mistakes:
  • Omitting 'self' parameter
  • Using 'function' keyword instead of 'def'
  • Incorrect method declaration keywords
3. Given the following class definition, what will be the output of print(car.get_speed()) after creating car = Car(50)?
class Car:
    def __init__(self, speed):
        self.speed = speed
    def get_speed(self):
        return self.speed
medium
A. 50
B. speed
C. None
D. Error

Solution

  1. Step 1: Understand object creation

    Creating car = Car(50) calls __init__, setting self.speed = 50.
  2. Step 2: Analyze get_speed method

    get_speed returns self.speed, which is 50.
  3. Final Answer:

    50 -> Option A
  4. Quick Check:

    car.get_speed() returns 50 [OK]
Hint: Constructor sets attributes, methods return them [OK]
Common Mistakes:
  • Confusing method return with attribute name
  • Expecting method to print instead of return
  • Forgetting to pass argument to constructor
4. Identify the error in the following class definition:
class Person:
    def __init__(self, name):
        name = name
    def get_name(self):
        return self.name
medium
A. The constructor does not assign to self.name
B. get_name method is missing self parameter
C. Class name should be lowercase
D. Constructor should not have parameters

Solution

  1. Step 1: Check constructor assignment

    The constructor assigns 'name = name' which only assigns local variable, not instance variable.
  2. Step 2: Check get_name method

    get_name returns self.name, but self.name was never set, causing error.
  3. Final Answer:

    The constructor does not assign to self.name -> Option A
  4. Quick Check:

    Instance variables need 'self.' prefix [OK]
Hint: Always assign instance variables with self. prefix [OK]
Common Mistakes:
  • Assigning to local variable instead of self attribute
  • Ignoring self parameter in methods
  • Misunderstanding naming conventions
5. You are designing a BankAccount class. Which of the following responsibilities should NOT be part of this class to keep it focused and maintainable?
hard
A. Providing methods to deposit and withdraw money
B. Storing account balance and updating it
C. Validating user identity during login
D. Generating account statements

Solution

  1. Step 1: Identify core responsibilities of BankAccount

    BankAccount should manage balance and transactions (deposit, withdraw) and possibly generate statements.
  2. Step 2: Analyze user identity validation

    User identity validation is a separate concern, better handled by an authentication class, not BankAccount.
  3. Final Answer:

    Validating user identity during login -> Option C
  4. Quick Check:

    Separate concerns keep classes focused [OK]
Hint: Keep authentication separate from account data [OK]
Common Mistakes:
  • Mixing unrelated responsibilities in one class
  • Overloading class with authentication logic
  • Ignoring single responsibility principle
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard