Bird
Raised Fist0
Software Engineeringknowledge~20 mins

SOLID principles in Software Engineering - Practice Problems & Coding Challenges

Choose your learning style10 modes available
Challenge - 5 Problems
🎖️
SOLID Mastery
Get all challenges correct to earn this badge!
Test your skills under time pressure!
🧠 Conceptual
intermediate
2:00remaining
Understanding the Single Responsibility Principle (SRP)

Which of the following best describes the Single Responsibility Principle?

AA class should depend on abstractions, not on concrete implementations.
BA class should have only one reason to change, meaning it should have only one job or responsibility.
CObjects of a superclass should be replaceable with objects of a subclass without affecting the correctness.
DA class should be open for modification but closed for extension.
Attempts:
2 left
💡 Hint

Think about how many reasons a class should have to change.

📋 Factual
intermediate
2:00remaining
Identifying the Open/Closed Principle (OCP)

Which statement correctly explains the Open/Closed Principle?

ADerived classes must be substitutable for their base classes.
BClasses should have only one responsibility.
CSoftware entities should be open for extension but closed for modification.
DDepend on concrete classes rather than abstractions.
Attempts:
2 left
💡 Hint

Consider how software should behave when new features are added.

🔍 Analysis
advanced
2:00remaining
Applying the Liskov Substitution Principle (LSP)

Given a base class Bird with a method fly(), and a subclass Penguin that cannot fly, which problem violates the Liskov Substitution Principle?

AReplacing <code>Bird</code> objects with <code>Penguin</code> objects causes errors when calling <code>fly()</code>.
BUsing interfaces to abstract bird behaviors.
CAdding new methods to <code>Bird</code> without changing <code>Penguin</code>.
DCreating a new subclass <code>Eagle</code> that can fly.
Attempts:
2 left
💡 Hint

Think about substituting a subclass where the base class is expected.

❓ Comparison
advanced
2:00remaining
Distinguishing Dependency Inversion Principle (DIP)

Which option best illustrates the Dependency Inversion Principle?

AHigh-level modules depend on abstractions, not on low-level modules.
BClasses should have only one reason to change.
CDerived classes must be substitutable for their base classes.
DSoftware entities should be open for extension but closed for modification.
Attempts:
2 left
💡 Hint

Consider the direction of dependencies between high-level and low-level modules.

❓ Reasoning
expert
3:00remaining
Evaluating Interface Segregation Principle (ISP) in Design

A software system has a large interface Printer with methods print(), scan(), and fax(). Some classes only need print(). What problem arises if these classes implement the full interface?

AThe system becomes open for extension but closed for modification.
BClasses will have multiple reasons to change, violating the Single Responsibility Principle.
CSubclasses cannot replace base classes without errors.
DClasses are forced to implement methods they do not use, violating the Interface Segregation Principle.
Attempts:
2 left
💡 Hint

Think about interfaces and how they should be designed for clients.

Practice

(1/5)
1. Which of the following best describes the Single Responsibility Principle (SRP) in SOLID?
easy
A. A class should have only one reason to change.
B. A class should inherit from multiple classes.
C. Functions should have multiple responsibilities.
D. Objects should be tightly coupled.

Solution

  1. Step 1: Understand SRP definition

    The Single Responsibility Principle states that a class should have only one reason to change, meaning it should have one job or responsibility.
  2. Step 2: Evaluate options

    A class should have only one reason to change.: A class should have only one reason to change. matches this definition exactly. Options B, C, and D contradict the principle by suggesting multiple responsibilities or tight coupling.
  3. Final Answer:

    A class should have only one reason to change. -> Option A
  4. Quick Check:

    SRP = One responsibility [OK]
Hint: SRP means one class, one job only [OK]
Common Mistakes:
  • Thinking SRP allows multiple responsibilities
  • Confusing SRP with inheritance rules
  • Believing tight coupling is allowed
2. Which of the following is the correct syntax to express the Open/Closed Principle (OCP)?
easy
A. Software entities should be open for modification but closed for extension.
B. Software entities should be closed for both extension and modification.
C. Software entities should be open for both extension and modification.
D. Software entities should be open for extension but closed for modification.

Solution

  1. Step 1: Recall OCP definition

    The Open/Closed Principle states that software entities should be open for extension but closed for modification, meaning you can add new features without changing existing code.
  2. Step 2: Match options to definition

    Software entities should be open for extension but closed for modification.: Software entities should be open for extension but closed for modification. correctly states this principle. Software entities should be open for modification but closed for extension. reverses the terms, and options B and D contradict the principle.
  3. Final Answer:

    Software entities should be open for extension but closed for modification. -> Option D
  4. Quick Check:

    OCP = Open extension, closed modification [OK]
Hint: OCP means add features, don't change old code [OK]
Common Mistakes:
  • Mixing up 'open for extension' and 'open for modification'
  • Thinking OCP allows changing existing code freely
  • Confusing OCP with SRP
3. Consider this code snippet applying the Liskov Substitution Principle (LSP):
class Bird:
    def fly(self):
        return "Flying"

class Penguin(Bird):
    def fly(self):
        return "Cannot fly"

bird = Bird()
penguin = Penguin()
print(bird.fly())
print(penguin.fly())

What is the output of this code?
medium
A. "Flying" followed by "Cannot fly"
B. "Flying" followed by "Flying"
C. Runtime error due to method override
D. "Cannot fly" followed by "Flying"

Solution

  1. Step 1: Analyze Bird and Penguin classes

    Bird has a fly method returning "Flying". Penguin overrides fly to return "Cannot fly".
  2. Step 2: Check print statements output

    bird.fly() returns "Flying". penguin.fly() returns "Cannot fly". So output is two lines: "Flying" then "Cannot fly".
  3. Final Answer:

    "Flying" followed by "Cannot fly" -> Option A
  4. Quick Check:

    bird.fly() = Flying, penguin.fly() = Cannot fly [OK]
Hint: Overridden methods can change output but not cause errors [OK]
Common Mistakes:
  • Assuming penguin.fly() returns "Flying"
  • Expecting runtime error from override
  • Confusing method outputs order
4. Identify the error in this code violating the Interface Segregation Principle (ISP):
class WorkerInterface:
    def work(self): pass
    def eat(self): pass

class Robot(WorkerInterface):
    def work(self):
        print("Working")
    def eat(self):
        raise Exception("Robots don't eat")
medium
A. Robot class must implement eat() with a print statement.
B. WorkerInterface should have only one method.
C. Robot class should not implement eat() if it doesn't apply.
D. No error; this code follows ISP.

Solution

  1. Step 1: Understand ISP

    Interface Segregation Principle says clients should not be forced to depend on methods they do not use.
  2. Step 2: Analyze Robot class

    Robot implements eat() but raises an exception because it doesn't eat. This violates ISP because Robot is forced to implement an irrelevant method.
  3. Final Answer:

    Robot class should not implement eat() if it doesn't apply. -> Option C
  4. Quick Check:

    ISP forbids unused methods in interfaces [OK]
Hint: ISP means no forced unused methods [OK]
Common Mistakes:
  • Thinking raising exception is acceptable
  • Believing interface must have only one method
  • Assuming no error if code runs
5. You have a payment system where new payment methods are added frequently. Which SOLID principle helps you design the system so you can add new payment types without changing existing code?
hard
A. Single Responsibility Principle
B. Open/Closed Principle
C. Liskov Substitution Principle
D. Dependency Inversion Principle

Solution

  1. Step 1: Identify the problem

    The system needs to add new payment methods often without modifying existing code.
  2. Step 2: Match with SOLID principles

    The Open/Closed Principle states software should be open for extension but closed for modification, exactly fitting this need.
  3. Final Answer:

    Open/Closed Principle -> Option B
  4. Quick Check:

    OCP = Add features without changing old code [OK]
Hint: OCP = add new without changing old [OK]
Common Mistakes:
  • Confusing SRP with OCP
  • Thinking LSP controls adding new types
  • Assuming Dependency Inversion solves this
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