SOLID: Stop Overloading Your Service Classes

Single Responsibility Principle (SRP)

👋 Hello, this is Valentina with the free edition of the Optivem Journal. I help Engineering Leaders & Senior Software Developers apply TDD in Legacy Code.

---

Ever opened a class and thought, ‘What does this thing even do?’

It starts small, but over time…

❌One Class Tries to Do It All

OrderService becomes the place where everything goes.

Need to send an email? Add it to OrderService.
Need to generate an invoice? Add it to OrderService.
Need to call the shipping API? Add it to OrderService.

Suddenly, the class looks like this:

OrderService

// Own reposponsibilities
- createOrder()
- cancelOrder()
- getOrderById()

// Extra responsibilities
- generateInvoice()
- shipOrder()
- sendEmail()
- trackOrder()

.... a laundry list of responsibilities...

At first, it feels convenient.

Each method is small.
Each feature made sense when it was added.

But over time, this class becomes large, fragile, and difficult to change…

Because it’s responsible for too many different things:

• order logic

• invoice generation

• shipping logic

• email notifications

One class does all of it.

---

💡Want to make it safe to redesign your architecture without breaking everything?

Limited spots. Early bird discount - 100 EUR off with code EARLYBIRD100

---

✅One Class, One Job

The Single Responsibility Principle (SRP) prevents this from happening.

A class should have one reason to change.

Not five. Not ten. One.

Instead of putting everything into OrderService, split responsibilities:

OrderService
- createOrder()
- cancelOrder()
- getOrderById()

InvoiceService
- generateInvoice()

EmailService
- sendEmail()

ShippingService
- shipOrder()
- trackOrder()

Now each class changes for one reason.

• Order logic changes → OrderService

• Invoice logic changes → InvoiceService

• Email logic changes → EmailService

• Shipping logic changes → ShippingService

💡SRP Isn’t About One Method or Tiny Classes