Bird
Raised Fist0

In a system where a class handles both payment processing and fraud detection, under what circumstance might combining these responsibilities still be justified despite SRP?

hard⚖️ Approach Comparison Q8 of Q15
OOP & Design Patterns - Single Responsibility Principle - One Class, One Reason to Change
In a system where a class handles both payment processing and fraud detection, under what circumstance might combining these responsibilities still be justified despite SRP?
AWhen splitting them would cause performance issues due to inter-class communication.
BWhen fraud detection is a minor part and unlikely to change independently.
CWhen the system is small and unlikely to evolve, so simplicity is preferred.
DWhen payment and fraud detection always change together and share the same reason to change.
Step-by-Step Solution
Solution:

  1. Step 1: Understand SRP's reason to change

    SRP allows combining responsibilities if they share the same reason to change.

  2. Step 2: Analyze payment and fraud detection

    If they always change together (e.g., regulatory updates), combining is justified.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Shared change reason permits combined responsibility [OK]
Quick Trick: SRP depends on reasons to change, not just functionality [OK]
Common Mistakes:
MISTAKES
  • Assuming SRP forbids any combined responsibilities
  • Prioritizing performance or size over change reasons
Trap Explanation:
PITFALL
  • Candidates often overlook that SRP allows combined responsibilities with a single change reason.
Interviewer Note:
CONTEXT
  • Tests nuanced understanding of SRP in edge cases.
Master "Single Responsibility Principle - One Class, One Reason to Change" in OOP & Design Patterns

2 interactive learning modes - each teaches the same concept differently

SolutionTrace

Want More Practice?

15+ quiz questions · All difficulty levels · Free

Free Signup - Practice All Questions
More OOP & Design Patterns Quizzes
Abstraction - Abstract Class vs Interface - When to Use Which - Abstraction - Abstract Class vs Interface - When to Use Which - Quiz 5medium Abstraction - Abstract Class vs Interface - When to Use Which - Abstraction - Abstract Class vs Interface - When to Use Which - Quiz 4medium Command Pattern - Undo/Redo, Request Queuing & Logging - Command Pattern - Undo/Redo, Request Queuing & Logging - Quiz 5medium Decorator Pattern - Wrapping Behaviour Without Subclassing - Decorator Pattern - Wrapping Behaviour Without Subclassing - Quiz 10hard Design Snake and Ladder Game - LLD End-to-End - Design Snake and Ladder Game - LLD End-to-End - Quiz 15hard Design a Parking Lot - LLD with OOP (Classes, Patterns, Extensibility) - Design a Parking Lot - LLD with OOP (Classes, Patterns, Extensibility) - Quiz 8hard Encapsulation - Data Hiding, Getters/Setters & Access Modifiers - Encapsulation - Data Hiding, Getters/Setters & Access Modifiers - Quiz 11easy Iterator & Composite Pattern - Traversal Abstractions - Iterator & Composite Pattern - Traversal Abstractions - Quiz 8hard Liskov Substitution Principle - Subtype Behavioural Contract - Liskov Substitution Principle - Subtype Behavioural Contract - Quiz 14medium Open/Closed Principle - Open for Extension, Closed for Modification - Open/Closed Principle - Open for Extension, Closed for Modification - Quiz 4medium