SOLID Principles Made Easy Quiz Quiz

Challenge your understanding of the SOLID principles of object-oriented design with this engaging quiz. Strengthen your grasp of best practices in software development by answering scenario-based questions focused on single responsibility, open/closed, Liskov substitution, interface segregation, and dependency inversion principles.

1. Single Responsibility Principle Scenario

   Which scenario best demonstrates the Single Responsibility Principle in action?

   1. A class responsible only for user authentication, while logging is handled by another class.
   2. A class that processes payments, prints invoices, and manages inventory.
   3. A database service that directly manages both user data and product catalogs.
   4. A function that sorts and formats data at the same time.

   Explanation: The correct answer is the class focused solely on user authentication, delegating logging to another class, since each class has one responsibility. A class that does payments, invoices, and inventory violates the principle by handling multiple concerns. Similarly, a function that both sorts and formats combines unrelated tasks. The database service managing user and product data mixes responsibilities, making the code harder to maintain.

2. Open/Closed Principle Example

   Which option best illustrates the Open/Closed Principle as applied in a payment system?

   1. Copying and pasting payment logic into separate files for each method.
   2. Adding new payment methods by creating subclasses without modifying the original payment class.
   3. Modifying the payment class code every time a new payment method is added.
   4. Only allowing a single payment method to be processed at a time.

   Explanation: Extending functionality through subclasses without altering the original code is the essence of the Open/Closed Principle. Modifying the payment class directly increases risk and reduces maintainability. Copying and pasting code leads to duplication and inconsistency, while restricting to a single payment method ignores extensibility altogether.

3. Liskov Substitution Principle Violation

   Which of the following examples violates the Liskov Substitution Principle?

   1. A child class inherits behavior and maintains all contracts satisfied by the parent class.
   2. An implementation where subclasses are used in place of parent classes without issues.
   3. A subclass overrides a method and throws an error for some inputs the parent accepted.
   4. A subclass provides the same functionality and interface as its base class.

   Explanation: The violation occurs when a subclass changes the behavior by rejecting inputs the parent would handle successfully, breaking substitutability. A subclass providing the same functionality upholds the principle. When a child class maintains the contract, there's no violation. Allowing subclasses to replace parents without errors aligns with the principle.

4. Interface Segregation Principle Application

   Which design best applies the Interface Segregation Principle to a device interface?

   1. Making all print, scan, and fax functions static in a utility class.
   2. Creating one large interface with print, scan, and fax methods that every device class implements.
   3. Defining separate interfaces for printing, scanning, and faxing, so a printer class only implements printing.
   4. Forcing all device classes to implement empty methods they don't need.

   Explanation: Segmenting interfaces allows classes to only implement what they need, respecting the Interface Segregation Principle. A large interface forces unrelated methods onto classes, making maintenance harder. Classes implementing empty methods leads to unnecessary code, and using static utility methods does not effectively use interface-based design.

5. Dependency Inversion Principle Understanding

   Which choice best demonstrates the Dependency Inversion Principle in software design?

   1. A high-level business logic class depends on an abstract interface rather than a specific database implementation.
   2. Changing the high-level class every time the database system changes.
   3. Directly creating and using specific database classes inside business logic functions.
   4. Hardcoding low-level module details inside high-level process flow code.

   Explanation: Depending on abstractions enables flexibility and decouples high-level logic from low-level details, as prescribed by the Dependency Inversion Principle. Changing the high-level class or hardcoding module details increases coupling. Directly creating and using concrete classes inside logic functions violates the principle by making the system rigid and harder to adapt.