Robust, maintainable code starts with one rule: don’t tie your core logic to how its data is stored.
A common mistake is locking a central class to a specific storage method. What starts as a quick localStorage.getItem()
quickly turns into a mess when you want to test, refactor, or adopt a new storage mechanism.
The Problem: A Model
Doing Too Much
At first, my Model
was doing it all. Managing state and worrying about persistence.
It was like Reba, a single mom, juggling too many roles at once. Too much for one class!
Example of tight coupling:
export class Model { private state: GameState = { /* ... default state ... */ }; constructor() { // Directly reading from localStorage this.state.scores.player = parseInt(localStorage.getItem('playerScore') || '0', 10); // ... many more localStorage.getItem calls }
Why This Was a Problem
- 👎 Tests weren’t isolated (every test depends on
localStorage
). - ⚡️ Low flexibility (switching to IndexedDB or an API means rewriting the
Model
). - ❌ Single Responsibility violated (business logic + storage concerns combined).
The Solution: Helping Model
Get a Break
Break the coupling by introducing an interface:
export interface IGameStorage { getScore(participant: Participant): number; setScore(participant: Participant, value: number): void; removeScore(participant: Participant): void; getRoundNumber(): number; setRoundNumber(value: number): void; removeRoundNumber(): void; // …other getters/setters as needed }
Then implement it:
export class LocalStorageGameStorage implements IGameStorage { getScore(participant: Participant): number { return parseInt(localStorage.getItem(`${participant}Score`) || '0', 10); } // … }
The Refactor: Small, Test‑Driven Changes
With a test suite in place, the refactor became a series of manageable steps:
✅ Confirm all existing tests were green.
✅ Replace one localStorage.getItem()
call with gameStorage.getScore()
.
✅ Run the test suite. Failures point to the next area that needs adjustment.
✅ Refine test setup by mocking IGameStorage
where needed.
✅ Repeat until every piece of state was abstracted.
Each test acted like a roadmap, making the refactor predictable and manageable.
The Refactored Model: Storage Abstraction in Action
export class Model { constructor(gameStorage: IGameStorage = new LocalStorageGameStorage()) { this.gameStorage = gameStorage; this.state.scores.player = this.gameStorage.getScore(PARTICIPANTS.PLAYER); this.state.scores.computer = this.gameStorage.getScore(PARTICIPANTS.COMPUTER); // ... no more direct persistence calls; Model is now truly persistence-agnostic }
Result: The Model
no longer knows (or cares) where its data comes from. All storage details are abstracted, making it easy to evolve and test.
What This Shows
✅ Abstraction makes code more flexible and testable.
✅ Tests turn refactoring into a safe, incremental process.
✅ Small changes reduce risk and save time in the long run.
The takeaway: Decoupling doesn’t have to be hard. Sometimes it’s as simple as extracting a few direct localStorage
calls and introducing an interface. The payoff (clarity, testability, maintainability) is worth it.
Remember: Much like Reba, who eventually finds help and balance, your code can too! 🫡
Top comments (0)