Separation of concerns in LLD - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to separate data storage from business logic.

LLD

class UserRepository:
    def __init__(self):
        self.users = []

    def [1](self, user):
        self.users.append(user)

Drag options to blanks, or click blank then click option'

Aupdate_user

Bget_user

Cdelete_user

Dadd_user

Attempts:

3 left

💡 Hint

Common Mistakes

Using a method name that implies retrieval instead of addition.

The method to add a user to the repository should be named add_user to clearly separate data storage actions.

2fill in blank

medium

Complete the code to separate user interface from data processing.

LLD

class UserInterface:
    def display_user(self, user):
        print(f"User: {user.name}")

class UserProcessor:
    def [1](self, user):
        user.name = user.name.upper()

Drag options to blanks, or click blank then click option'

Aprocess_user

Bdelete_user

Csave_user

Ddisplay_user

Attempts:

3 left

💡 Hint

Common Mistakes

Naming the method display_user which mixes UI with processing.

The method that changes user data should be named process_user to separate processing from display.

3fill in blank

hard

Fix the error in the code to properly separate logging from business logic.

LLD

class OrderService:
    def place_order(self, order):
        # Business logic here
        [1].log(f"Order placed: {order.id}")

Drag options to blanks, or click blank then click option'

ALogger

Border

Cself

DOrderService

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'self' or 'order' to call log, mixing concerns.

The logging should be done by a separate Logger class or instance, not by the order or service itself.

4fill in blank

hard

Fill both blanks to separate configuration from application logic.

LLD

class AppConfig:
    def __init__(self):
        self.settings = {"db_host": "localhost", "db_port": 5432}

class Application:
    def __init__(self, config):
        self.db_host = config.[1]["db_host"]
        self.db_port = config.[2]["db_port"]

Drag options to blanks, or click blank then click option'

Asettings

Bdb_host

Cdb_port

Dconfig

Attempts:

3 left

💡 Hint

Common Mistakes

Trying to access db_host directly on config instead of inside settings.

The application accesses configuration values from the settings dictionary, using keys like db_host.

5fill in blank

hard

Fill all three blanks to separate data validation, storage, and notification.

LLD

class Validator:
    def validate(self, data):
        return data is not None

class Storage:
    def save(self, data):
        print(f"Saving {data}")

class Notifier:
    def notify(self, message):
        print(f"Notify: {message}")

class Service:
    def __init__(self, validator, storage, notifier):
        self.validator = validator
        self.storage = storage
        self.notifier = notifier

    def process(self, data):
        if self.validator.[1](data):
            self.storage.[2](data)
            self.notifier.[3]("Data processed successfully")

Drag options to blanks, or click blank then click option'

Avalidate

Bsave

Cnotify

Dprocess

Attempts:

3 left

💡 Hint

Common Mistakes

Mixing method names or calling process instead of validate.

The service calls validate to check data, save to store it, and notify to send a message, keeping concerns separate.

Practice

1. What is the main purpose of separation of concerns in system design?

easy

A. To divide a system into parts that each handle a specific job

B. To combine all system functions into one module

C. To make the system run faster by using fewer parts

D. To remove all interfaces between system components

Solution

1. Step 1: Understand the concept of separation of concerns

   It means dividing a system into parts where each part has a clear, specific responsibility.

2. Step 2: Compare options with the concept

   Only To divide a system into parts that each handle a specific job describes dividing the system into parts with specific jobs, matching the concept.

3. Final Answer:

   To divide a system into parts that each handle a specific job -> Option A

4. Quick Check:

   Separation of concerns = divide system parts [OK]

Hint: Think: separate jobs make systems simpler [OK]

Common Mistakes:

• Confusing separation with combining functions
• Thinking it speeds up system by reducing parts
• Ignoring the role of interfaces

2. Which of the following is the correct way to apply separation of concerns in code structure?

easy

A. Separating UI code, business logic, and data access into different modules

B. Writing all code in one large file for easy access

C. Mixing UI logic and data processing in the same function

D. Ignoring interfaces between different parts

Solution

1. Step 1: Identify proper separation in code

   Separation of concerns means keeping UI, logic, and data handling separate.

2. Step 2: Match options to this principle

   Separating UI code, business logic, and data access into different modules correctly separates these concerns into different modules.

3. Final Answer:

   Separating UI code, business logic, and data access into different modules -> Option A

4. Quick Check:

   Separate UI, logic, data = Separating UI code, business logic, and data access into different modules [OK]

Hint: Keep UI, logic, data in separate files [OK]

Common Mistakes:

• Mixing UI and logic in one place
• Putting all code in one file
• Ignoring module boundaries

3. Consider this simplified code snippet applying separation of concerns:

class DataFetcher:
    def fetch(self):
        return "data"

class Processor:
    def process(self, data):
        return data.upper()

class UI:
    def display(self, processed_data):
        print(processed_data)

fetcher = DataFetcher()
data = fetcher.fetch()
processor = Processor()
processed = processor.process(data)
ui = UI()
ui.display(processed)

What will be printed when this code runs?

medium

A. processor

B. data

C. fetch

D. DATA

Solution

1. Step 1: Trace data flow through classes

   DataFetcher returns "data". Processor converts it to uppercase "DATA". UI prints it.

2. Step 2: Determine final output

   The UI prints the processed data, which is "DATA" in uppercase.

3. Final Answer:

   DATA -> Option D

4. Quick Check:

   Uppercase processed data = DATA [OK]

Hint: Follow data from fetch to display [OK]

Common Mistakes:

• Confusing original data with processed data
• Ignoring the uppercase conversion
• Thinking print shows method names

4. In a system designed with separation of concerns, which issue indicates a violation of this principle?

medium

A. Clear division of responsibilities between components

B. Separate modules for UI and data storage communicating via interfaces

C. A module handling both user input validation and database queries

D. Using interfaces to connect independent parts

Solution

1. Step 1: Identify violation of separation of concerns

   A module doing multiple unrelated jobs breaks the principle.

2. Step 2: Match options to violation

   A module handling both user input validation and database queries shows one module handling both validation and database queries, mixing concerns.

3. Final Answer:

   A module handling both user input validation and database queries -> Option C

4. Quick Check:

   Mixed responsibilities = violation [OK]

Hint: One module, one job only [OK]

Common Mistakes:

• Thinking interfaces cause violation
• Believing clear division is a problem
• Confusing separation with duplication

5. You are designing a web application with separation of concerns. Which design choice best supports this principle while ensuring scalability?

hard

A. Combine UI rendering, business logic, and data access in a single service

B. Use separate services for UI, business logic, and data storage connected via APIs

C. Store all data and logic in the client-side code for faster access

D. Avoid defining clear interfaces between components to reduce complexity

Solution

1. Step 1: Understand separation and scalability needs

   Separation means dividing concerns; scalability means easy to grow and maintain.

2. Step 2: Evaluate design options

   Use separate services for UI, business logic, and data storage connected via APIs uses separate services connected by APIs, which keeps concerns separate and supports scaling.

3. Final Answer:

   Use separate services for UI, business logic, and data storage connected via APIs -> Option B

4. Quick Check:

   Separate services + APIs = scalable separation [OK]

Hint: Separate services with APIs scale best [OK]

Common Mistakes:

• Combining all logic in one service
• Putting logic only on client side
• Skipping interfaces between parts