Class responsibilities and behavior in LLD - System Design Exercise

Design: Class Responsibilities and Behavior Design

Focus on designing class responsibilities and behaviors in object-oriented design. Exclude implementation details like database or UI specifics.

Functional Requirements

FR1: Define clear responsibilities for each class in a system

FR2: Ensure classes have single, well-defined behaviors

FR3: Support interaction between classes through well-designed methods

FR4: Promote code reusability and maintainability

FR5: Allow easy extension or modification of class behaviors

Non-Functional Requirements

NFR1: Classes should follow the Single Responsibility Principle

NFR2: Interactions should minimize tight coupling

NFR3: Design should be understandable by developers with basic OOP knowledge

NFR4: Performance impact should be minimal for typical use cases

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

Classes and their methods

Attributes representing class state

Interfaces or abstract classes for behavior contracts

Relationships like inheritance, composition, and aggregation

Design principles like SRP, encapsulation, and polymorphism

Design Patterns

Single Responsibility Principle (SRP)

Strategy pattern for interchangeable behaviors

Observer pattern for event-driven behavior

Command pattern for encapsulating requests

Decorator pattern for extending behavior dynamically

Reference Architecture

  +----------------+       +----------------+
  |   Class A      |       |   Class B      |
  |----------------|       |----------------|
  | - attribute1   |       | - attribute2   |
  |----------------|       |----------------|
  | + behavior1()  |<----->| + behavior2()  |
  +----------------+       +----------------+

  Classes have clear responsibilities and communicate via methods.

Components

Class

Object-Oriented Programming

Encapsulates data and behaviors related to a single responsibility.

Methods

OOP Methods

Define behaviors that the class can perform or expose.

Attributes

Class Fields

Store the state or data relevant to the class.

Interfaces/Abstract Classes

OOP Abstractions

Define contracts for behaviors that multiple classes can implement.

Relationships

Inheritance, Composition, Aggregation

Model how classes relate and collaborate to fulfill system behavior.

Request Flow

1. 1. Client calls a method on Class A to perform an action.

2. 2. Class A executes its behavior using its attributes.

3. 3. If needed, Class A calls a method on Class B to delegate part of the behavior.

4. 4. Class B performs its behavior and returns results to Class A.

5. 5. Class A completes the action and returns the result to the client.

Database Schema

Not applicable as this design focuses on class responsibilities and behavior rather than data persistence.

Scaling Discussion

Bottlenecks

Classes with too many responsibilities become hard to maintain.

Tight coupling between classes reduces flexibility and increases bugs.

Large inheritance hierarchies can be complex and fragile.

Behavior changes require modifying multiple classes if not well abstracted.

Solutions

Apply Single Responsibility Principle to split classes with multiple responsibilities.

Use interfaces and dependency injection to reduce coupling.

Favor composition over inheritance to build flexible behaviors.

Use design patterns like Strategy or Decorator to extend behavior without modifying existing classes.

Interview Tips

Time: Spend 10 minutes defining class responsibilities and behaviors, 15 minutes discussing interactions and design principles, and 20 minutes explaining patterns and scalability.

Explain how each class has a single clear responsibility.

Describe how behaviors are encapsulated in methods.

Discuss how classes communicate with minimal coupling.

Highlight use of design principles like SRP and encapsulation.

Show understanding of patterns to extend or modify behavior safely.

Practice

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