Up to this point, you’ve learned:
- how to understand requirements
- how to break systems
- how to apply SOLID principles
But a practical question still remains:
How do you evaluate whether a design is good or not?
Two concepts help you answer that:
Cohesion and Coupling
The hidden problem in most designs
Consider this:
OrderService:
- create_order()
- process_payment()
- send_email()
- generate_invoice()
At first glance, this may seem organized.
All order-related actions are in one place.
But look closer:
- order creation
- payment processing
- notifications
- billing
These are not the same responsibility.
This is where design quality starts breaking.
Cohesion — how focused a component is
Cohesion measures how closely related the responsibilities inside a module are.
Low cohesion (bad design)
A class doing:
- multiple unrelated tasks
- mixing business logic with external concerns
Like the previous example:
- OrderService is doing everything
This leads to:
- harder understanding
- difficult testing
- risky changes
High cohesion (good design)
Break responsibilities:
OrderService → create_order()
PaymentService → process_payment()
NotificationService → send_email()
InvoiceService → generate_invoice()
Now:
- each class has a single, clear purpose
- logic is easier to reason about
Key insight
A cohesive class answers one question clearly.
Coupling — how dependent components are
Coupling measures how much one component depends on others.
High coupling (bad design)
If OrderService directly:
- calls payment logic
- sends emails
- generates invoices
Then:
- it depends on multiple systems
- any change in those systems affects it
Low coupling (good design)
Introduce separation:
- Services are independent
- Communication happens via clear interfaces
Optionally, introduce an orchestrator:
OrderOrchestrator:
- create_order()
- process_payment()
- send_notification()
- generate_invoice()
Now:
- services don’t depend on each other
- flow is managed separately
Key insight
Low coupling reduces the ripple effect of changes.
How cohesion and coupling work together
Good design aims for:
- High Cohesion → each module is focused
- Low Coupling → modules are independent
If you get both right:
- code is easier to maintain
- features are easier to add
- bugs are easier to isolate
A practical way to evaluate your design
Ask yourself:
- Does this class have more than one responsibility? → Cohesion issue
- Will a change in one part affect many others? → Coupling issue
If the answer is yes, your design needs refinement.
A subtle but important shift
Beginners often think:
“Everything in one place is easier.”
Experienced engineers think:
“Clear separation makes systems easier to evolve.”
Closing thought
Good design is not about adding more structure.
It’s about placing responsibilities in the right place, and keeping dependencies under control.
