Why this matters
- A class should have one reason to change — one stakeholder group whose decisions affect it
- High cohesion: methods share a single purpose and reuse private state
- Before: one
InvoiceServicewith tax, HTML, and SMTP inline - Do not create one class per method — that is over-engineering
- SOLID is scored as refactor skill, not acronym recall.
SRPOne reason to change
OCPExtend, don't modify
LSPSubtypes substitutable
ISPSmall interfaces
DIPDepend on abstractions
Overview
Split classes by reason to change, not by line count. Study each section below in order — every list is interview-ready reference material.
Reasons to change
Points to cover
- A class should have one reason to change — one stakeholder group whose decisions affect it
- Invoice example: tax rules, report format, and email delivery are three reasons → three classes
OrderServiceshould coordinate, not implement tax math or HTML rendering- Ask aloud: 'If I change X policy, which classes must I edit?'
- More than one answer → split responsibilities
Cohesion test
Points to cover
- High cohesion: methods share a single purpose and reuse private state
- Low cohesion: unrelated methods grouped because 'they're all about orders'
- File size is not the test — two methods can be one class if they change together
- CampusOS:
ParkingSpotowns occupy/vacate; it does not send emails
CampusOS invoice refactor
Points to cover
- Before: one
InvoiceServicewith tax, HTML, and SMTP inline - After:
TaxCalculator,InvoiceRenderer,EmailSender, thinInvoiceService - Each new tax region adds a strategy, not an if-branch in one class
- Unit test each collaborator in isolation
When not to split
Points to cover
- Do not create one class per method — that is over-engineering
- Keep data + behaviour together when they always change as a unit
- Value objects stay small and focused without extra layers
- Split when a second independent reason to change actually appears
// CampusOS — apply "Reasons to change" on paper first, then in code
public final class SrpAndCohesionExample {
// 1. Name entities from the problem statement
// 2. Draw relationships before writing methods
// 3. Introduce patterns only when a force appears
}
Quick recall
Everything you need if you only revisit this box.
- Reasons to change — review this slice before mock interviews.
- Cohesion test — review this slice before mock interviews.
- CampusOS invoice refactor — review this slice before mock interviews.
- When not to split — review this slice before mock interviews.
Test yourself
Answer these before moving on — recall is what makes it stick.