Navigating Large CodebasesLesson 3.5
How to read a design pattern you didn't write
recognizing common patterns, Observer pattern, Factory pattern, Singleton, Repository pattern, Middleware pattern, when patterns become anti-patterns
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.