Key point
One review path
Your repo should let a reviewer move from problem to refactor to proof in under five minutes.
Do not just show neat final code. Show the messy pain, the pattern you used, and why the change helped.
Your to-do
Design Patterns
Your repo should let a reviewer move from problem to refactor to proof in under five minutes.
Do not just show neat final code. Show the messy pain, the pattern you used, and why the change helped.
0 of 8 lessons done · proved by a submitted project with a public repository
Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.
0 of 5 done
Use the README as your viva answer. A recruiter should not need to guess why you used Factory, Strategy, Observer, Repository, DI, or skipped Singleton.
# Pattern Refactor: Campus Expense Splitter
## What this app does
Students can add shared expenses, split amounts, and view balances.
## How to run
npm install
npm test
npm run dev
## Before refactor
The first version had payment logic, storage calls, and notification code inside the same service.
This made small changes risky.
## Refactors made
| Pattern | Problem it solved | Main files | Commit |
| --- | --- | --- | --- |
| Factory | Creating UPI, cash, and card payments had repeated if-else code | src/payments/paymentFactory.js | abc123 |
| Strategy | Split rules changed often: equal, percentage, exact amount | src/splits/strategies | def456 |
| Observer | Balance updates needed to notify UI and audit log without coupling them | src/events | ghi789 |
| Repository | Data access was mixed into business logic | src/repositories | jkl012 |
| Dependency Injection | Tests needed fake repositories and fake notifiers | src/container.js | mno345 |
## Pattern I did not use
I did not use Singleton for the database client.
The app is small, and passing the dependency explicitly made tests easier.
A Singleton would hide shared state and make test order bugs more likely.
## Proof
- Tests pass with npm test
- Screenshots are in /docs/screenshots
- Before branch: before-refactor
- Final branch: mainAsk AI to review your README for missing proof, not to invent reasons. Paste your real file tree and commit list.
Check every suggestion against your code. If the README says Strategy but your code still has one giant if-else, fix the code or remove the claim.
Prompt:
Review this README for a pattern refactor repo.
Tell me what proof is missing.
Do not add patterns I did not implement.
Here is my file tree:
[paste tree]
Here are my commits:
[paste commit messages]Four patterns are required for this track proof, but more is not automatically better. A repo with six patterns and no clear problem looks weaker than a repo with four useful refactors.
Also include one pattern you rejected. This shows judgement, which is the real skill.
Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.
0 of 5 done
Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.
0 of 5 done
Answer the quick check to finish this lesson.