Lesson 1: SRP and responsible objects
Picture one OrderService class that validates input, charges a credit card, and sends a confirmation email. A designer asks for a small wording tweak in the email's subject line — a change that looks harmless — and suddenly cart-quantity validation breaks, because that logic and the email formatting
Split validation, pricing, and persistence so each class has one reason to change.
- SRP and responsible objects
- Split validation, pricing, and persistence so each class has one reason to change.
- design pressure
- A repeated change, duplication, or test pain that signals the model needs a better boundary.
