← Back to Week 1 Hub

Method Decomposition

Breaking a big main() into small, focused methods — the art of refactoring

1
2
3
4
The Monolith
Everything lives inside main(). It works, but it is hard to read, hard to reuse, and hard to maintain. Can you spot the different "jobs" this code is doing?

Why Methods?

📖 Readability
After refactoring, main() reads like a story: get name, get hours, get rate, calculate pay, display results. Anyone can understand the program flow in seconds.
Reusability
Need to calculate gross pay somewhere else in the program? Just call calculateGrossPay(hours, rate) again. No copy-pasting code.
💧 DRY Principle
Don't Repeat Yourself. If you need the same logic twice, put it in a method. One place to fix bugs, one place to update.
Scanner Rule: Create Scanner once in main(), then pass it as a parameter to any method that needs user input. Never re-declare it.

Refactoring Checklist

☐ Identify distinct "chunks" of work
☐ Name each chunk (= method name)
☐ Decide parameters (what goes in?)
☐ Decide return type (what comes out?)
☐ Extract to a method
☐ Replace chunk with method call
☐ Verify main() reads like a story
Naming Tip: When refactoring, ask yourself: "What does this chunk DO?" The answer becomes the method name. getName(), calculateGrossPay(), displayResults() — your method names should describe exactly what they do.
← Method Call Stack Scanner in Multiple Methods →