How to read a design pattern you didn't write

Patterns Are Named Shapes

Design patterns are recurring solutions to recurring problems. When you recognize a pattern in unfamiliar code, you instantly know the intent, the roles of each component, and the expected behavior — without reading all the implementation details.

Recognizing Common Patterns

// Observer Pattern: subscribe to events
eventBus.on('user:created', sendWelcomeEmail);
eventBus.on('user:created', createDefaultSettings);
eventBus.emit('user:created', { id: '123', email: 'a@b.com' });
// Reading: one event → multiple independent handlers
// Known behavior: handlers are decoupled from the emitter

// Repository Pattern: abstract data access
class UserRepository {
  async findById(id) { return db.users.findOne({ id }); }
  async save(user) { return db.users.upsert(user); }
  async delete(id) { return db.users.deleteOne({ id }); }
}
// Reading: data access is abstracted — you can swap the DB without changing business logic

// Middleware Pattern (Express style): chain of handlers
app.use(authenticate);
app.use(rateLimit);
app.use(validateInput);
// Reading: each function runs in order; any can stop the chain by not calling next()

When Patterns Signal Trouble

A Singleton used everywhere for mutable state is global state in disguise. A Factory that has 200 lines of conditionals has become a God function. Recognizing the pattern helps you spot when it's been applied correctly versus when it's become a problem.