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.
Top comments (0)