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)