Part 5: SOLID Principles and Design Patterns - Production-Ready Code

Introduction

My first large codebase became unmaintainable at 50,000 lines. Changing one feature broke three others. Adding tests required mocking 15 dependencies. New developers took weeks to understand the architecture. The problem? I violated every SOLID principle and mixed design patterns incorrectly.

I refactored following SOLID principles. Single Responsibility: each class did one thing. Open/Closed: extended behavior without modifying code. Liskov Substitution: subclasses worked anywhere parent worked. Interface Segregation: clients only depended on methods they used. Dependency Inversion: depended on abstractions, not concretions. Combined with proven design patterns, the system became maintainable, testable, and extensible.

This article teaches you the five SOLID principles, essential design patterns, and how to build production-ready TypeScript applications.

SOLID Principles

S - Single Responsibility Principle (SRP)

A class should have one, and only one, reason to change.

Problem: Multiple Responsibilities

// Bad - User class does too much
class User {
    constructor(
        public id: string,
        public username: string,
        public email: string,
        public password: string
    ) {}
    
    // Responsibility 1: User data management
    updateEmail(email: string): void {
        this.email = email;
    }
    
    // Responsibility 2: Password hashing
    hashPassword(): void {
        this.password = crypto.createHash('sha256').update(this.password).digest('hex');
    }
    
    // Responsibility 3: Database operations
    save(): void {
        console.log(`Saving user ${this.id} to database`);
        // db.query('INSERT INTO users...');
    }
    
    // Responsibility 4: Email notifications
    sendWelcomeEmail(): void {
        console.log(`Sending welcome email to ${this.email}`);
        // emailService.send(...);
    }
    
    // Responsibility 5: Validation
    validate(): boolean {
        return this.username.length >= 3 && this.email.includes('@');
    }
}

Problems:

• User class changes when password hashing algorithm changes

• User class changes when database schema changes

• User class changes when email template changes

• Hard to test each concern in isolation

• Cannot reuse password hashing in other classes

Solution: Separate Responsibilities

// User entity - only data
class User {
    constructor(
        public id: string,
        public username: string,
        public email: string,
        private passwordHash: string
    ) {}
    
    getPasswordHash(): string {
        return this.passwordHash;
    }
    
    updateEmail(email: string): void {
        this.email = email;
    }
}

// Password service - handles hashing
class PasswordService {
    hash(password: string): string {
        return crypto.createHash('sha256').update(password).digest('hex');
    }
    
    verify(password: string, hash: string): boolean {
        return this.hash(password) === hash;
    }
}

// User repository - handles persistence
interface UserRepository {
    save(user: User): Promise<void>;
    findById(id: string): Promise<User | null>;
    findByEmail(email: string): Promise<User | null>;
}

class DatabaseUserRepository implements UserRepository {
    async save(user: User): Promise<void> {
        console.log(`Saving user ${user.id} to database`);
        // await db.query('INSERT INTO users...');
    }
    
    async findById(id: string): Promise<User | null> {
        console.log(`Finding user by id: ${id}`);
        // const result = await db.query('SELECT * FROM users WHERE id = ?', [id]);
        return null;
    }
    
    async findByEmail(email: string): Promise<User | null> {
        console.log(`Finding user by email: ${email}`);
        return null;
    }
}

// Email service - handles notifications
interface EmailService {
    send(to: string, subject: string, body: string): Promise<void>;
}

class SendGridEmailService implements EmailService {
    async send(to: string, subject: string, body: string): Promise<void> {
        console.log(`Sending email to ${to}: ${subject}`);
    }
}

// User validator - handles validation
class UserValidator {
    validate(user: User): { valid: boolean; errors: string[] } {
        const errors: string[] = [];
        
        if (user.username.length < 3) {
            errors.push('Username must be at least 3 characters');
        }
        
        if (!user.email.includes('@')) {
            errors.push('Invalid email format');
        }
        
        return {
            valid: errors.length === 0,
            errors
        };
    }
}

// Orchestration - uses all services
class UserRegistrationService {
    constructor(
        private userRepository: UserRepository,
        private passwordService: PasswordService,
        private emailService: EmailService,
        private validator: UserValidator
    ) {}
    
    async register(username: string, email: string, password: string): Promise<User> {
        // Hash password
        const passwordHash = this.passwordService.hash(password);
        
        // Create user
        const user = new User(crypto.randomUUID(), username, email, passwordHash);
        
        // Validate
        const validation = this.validator.validate(user);
        if (!validation.valid) {
            throw new Error(`Validation failed: ${validation.errors.join(', ')}`);
        }
        
        // Save
        await this.userRepository.save(user);
        
        // Send welcome email
        await this.emailService.send(
            user.email,
            'Welcome!',
            `Hello ${user.username}, welcome to our platform!`
        );
        
        return user;
    }
}

Benefits:

• Each class has one reason to change

• Easy to test each class in isolation

• Can reuse PasswordService anywhere

• Can swap database or email provider easily

O - Open/Closed Principle (OCP)

Software entities should be open for extension, but closed for modification.

Problem: Modifying Existing Code

// Bad - must modify class to add new payment types
class PaymentProcessor {
    processPayment(type: string, amount: number): void {
        if (type === 'credit_card') {
            console.log(`Processing credit card payment: $${amount}`);
            // Credit card logic
        } else if (type === 'paypal') {
            console.log(`Processing PayPal payment: $${amount}`);
            // PayPal logic
        } else if (type === 'bank_transfer') {
            console.log(`Processing bank transfer: $${amount}`);
            // Bank transfer logic
        }
        // Adding crypto requires modifying this class!
    }
}

Problems:

• Must modify PaymentProcessor for each new payment type

• Risk breaking existing payment types

• All logic in one place - hard to maintain

• Cannot test payment types independently

Solution: Extend Through Abstraction

// Good - extend by adding new classes
interface PaymentMethod {
    process(amount: number): Promise<void>;
}

class CreditCardPayment implements PaymentMethod {
    constructor(private cardNumber: string) {}
    
    async process(amount: number): Promise<void> {
        console.log(`Processing credit card payment: $${amount}`);
        console.log(`Card: ****${this.cardNumber.slice(-4)}`);
        // Credit card logic
    }
}

class PayPalPayment implements PaymentMethod {
    constructor(private email: string) {}
    
    async process(amount: number): Promise<void> {
        console.log(`Processing PayPal payment: $${amount}`);
        console.log(`Account: ${this.email}`);
        // PayPal logic
    }
}

class BankTransferPayment implements PaymentMethod {
    constructor(private accountNumber: string) {}
    
    async process(amount: number): Promise<void> {
        console.log(`Processing bank transfer: $${amount}`);
        console.log(`Account: ${this.accountNumber}`);
        // Bank transfer logic
    }
}

// NEW: Add crypto without modifying existing code
class CryptoPayment implements PaymentMethod {
    constructor(private walletAddress: string) {}
    
    async process(amount: number): Promise<void> {
        console.log(`Processing crypto payment: $${amount}`);
        console.log(`Wallet: ${this.walletAddress}`);
        // Crypto logic
    }
}

class PaymentProcessor {
    async process(method: PaymentMethod, amount: number): Promise<void> {
        await method.process(amount);
    }
}

// Usage - no changes to PaymentProcessor needed
const processor = new PaymentProcessor();

await processor.process(new CreditCardPayment('4532123456789012'), 100);
await processor.process(new PayPalPayment('[email protected]'), 50);
await processor.process(new CryptoPayment('0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb'), 200);

L - Liskov Substitution Principle (LSP)

Subtypes must be substitutable for their base types.

Problem: Broken Substitution

// Bad - Square violates LSP
class Rectangle {
    constructor(
        protected width: number,
        protected height: number
    ) {}
    
    setWidth(width: number): void {
        this.width = width;
    }
    
    setHeight(height: number): void {
        this.height = height;
    }
    
    getArea(): number {
        return this.width * this.height;
    }
}

class Square extends Rectangle {
    setWidth(width: number): void {
        this.width = width;
        this.height = width;  // Square must maintain width === height
    }
    
    setHeight(height: number): void {
        this.width = height;  // Square must maintain width === height
        this.height = height;
    }
}

function testRectangle(rect: Rectangle): void {
    rect.setWidth(5);
    rect.setHeight(10);
    
    // Expect area to be 50 for Rectangle
    // But Square gives 100! (10 * 10)
    console.log(`Area: ${rect.getArea()}`);
}

testRectangle(new Rectangle(0, 0));  // Area: 50 ✓
testRectangle(new Square(0, 0));     // Area: 100 ✗ - LSP violated!

Problem: Square changes behavior of setWidth/setHeight, breaking expectations.

Solution: Proper Abstraction

// Good - use composition or separate hierarchies
interface Shape {
    getArea(): number;
}

class Rectangle implements Shape {
    constructor(
        private width: number,
        private height: number
    ) {}
    
    setWidth(width: number): void {
        this.width = width;
    }
    
    setHeight(height: number): void {
        this.height = height;
    }
    
    getArea(): number {
        return this.width * this.height;
    }
}

class Square implements Shape {
    constructor(private size: number) {}
    
    setSize(size: number): void {
        this.size = size;
    }
    
    getArea(): number {
        return this.size * this.size;
    }
}

// Now both implement Shape but have different APIs
function calculateTotalArea(shapes: Shape[]): number {
    return shapes.reduce((sum, shape) => sum + shape.getArea(), 0);
}

const shapes: Shape[] = [
    new Rectangle(5, 10),
    new Square(5)
];

console.log(calculateTotalArea(shapes));  // 75 - works correctly!

I - Interface Segregation Principle (ISP)

Clients should not be forced to depend on interfaces they do not use.

Problem: Fat Interface

// Bad - fat interface forces unnecessary dependencies
interface Worker {
    work(): void;
    eat(): void;
    sleep(): void;
    attendMeeting(): void;
    writeCode(): void;
    fixBugs(): void;
}

// Robot worker doesn't eat or sleep!
class RobotWorker implements Worker {
    work(): void {
        console.log('Robot working');
    }
    
    // Forced to implement but doesn't make sense
    eat(): void {
        throw new Error('Robots do not eat');
    }
    
    sleep(): void {
        throw new Error('Robots do not sleep');
    }
    
    attendMeeting(): void {
        console.log('Robot attending meeting');
    }
    
    writeCode(): void {
        console.log('Robot writing code');
    }
    
    fixBugs(): void {
        console.log('Robot fixing bugs');
    }
}

Solution: Segregated Interfaces

// Good - small, focused interfaces
interface Workable {
    work(): void;
}

interface Eatable {
    eat(): void;
}

interface Sleepable {
    sleep(): void;
}

interface Codeable {
    writeCode(): void;
    fixBugs(): void;
}

interface Attendable {
    attendMeeting(): void;
}

// Human implements all
class HumanWorker implements Workable, Eatable, Sleepable, Codeable, Attendable {
    work(): void {
        console.log('Human working');
    }
    
    eat(): void {
        console.log('Human eating');
    }
    
    sleep(): void {
        console.log('Human sleeping');
    }
    
    writeCode(): void {
        console.log('Human writing code');
    }
    
    fixBugs(): void {
        console.log('Human fixing bugs');
    }
    
    attendMeeting(): void {
        console.log('Human attending meeting');
    }
}

// Robot only implements relevant interfaces
class RobotWorker implements Workable, Codeable {
    work(): void {
        console.log('Robot working');
    }
    
    writeCode(): void {
        console.log('Robot writing code');
    }
    
    fixBugs(): void {
        console.log('Robot fixing bugs');
    }
}

// Functions depend only on what they need
function assignWork(worker: Workable): void {
    worker.work();
}

function scheduleBreak(worker: Eatable & Sleepable): void {
    worker.eat();
    worker.sleep();
}

const human = new HumanWorker();
const robot = new RobotWorker();

assignWork(human);  // Works
assignWork(robot);  // Works

scheduleBreak(human);  // Works
// scheduleBreak(robot);  // Compile error - robot doesn't implement Eatable/Sleepable ✓

D - Dependency Inversion Principle (DIP)

Depend on abstractions, not concretions.

Problem: High-level Depends on Low-level

// Bad - OrderService depends on concrete MySQL class
class MySQLDatabase {
    query(sql: string): any {
        console.log(`MySQL query: ${sql}`);
        return { id: 1, name: 'Product' };
    }
}

class OrderService {
    private db = new MySQLDatabase();  // Tightly coupled!
    
    createOrder(productId: string, quantity: number): void {
        const product = this.db.query(`SELECT * FROM products WHERE id = ${productId}`);
        console.log(`Creating order for ${product.name}`);
    }
}

Problems:

• Cannot swap MySQL for PostgreSQL

• Cannot test OrderService without MySQL

• OrderService knows about low-level database details

Solution: Depend on Abstraction

// Good - depend on interface
interface Database {
    query(sql: string): Promise<any>;
}

class MySQLDatabase implements Database {
    async query(sql: string): Promise<any> {
        console.log(`MySQL query: ${sql}`);
        return { id: 1, name: 'Product' };
    }
}

class PostgresDatabase implements Database {
    async query(sql: string): Promise<any> {
        console.log(`Postgres query: ${sql}`);
        return { id: 1, name: 'Product' };
    }
}

class MockDatabase implements Database {
    async query(sql: string): Promise<any> {
        return { id: 1, name: 'Mock Product' };
    }
}

class OrderService {
    constructor(private db: Database) {}  // Depends on abstraction!
    
    async createOrder(productId: string, quantity: number): Promise<void> {
        const product = await this.db.query(`SELECT * FROM products WHERE id = ${productId}`);
        console.log(`Creating order for ${product.name}`);
    }
}

// Flexible - swap implementation
const mysqlService = new OrderService(new MySQLDatabase());
const postgresService = new OrderService(new PostgresDatabase());
const testService = new OrderService(new MockDatabase());

Essential Design Patterns

Factory Pattern

Create objects without specifying exact class:

interface Notification {
    send(message: string): void;
}

class EmailNotification implements Notification {
    send(message: string): void {
        console.log(`Email: ${message}`);
    }
}

class SMSNotification implements Notification {
    send(message: string): void {
        console.log(`SMS: ${message}`);
    }
}

class PushNotification implements Notification {
    send(message: string): void {
        console.log(`Push: ${message}`);
    }
}

// Factory
class NotificationFactory {
    static create(type: 'email' | 'sms' | 'push'): Notification {
        switch (type) {
            case 'email':
                return new EmailNotification();
            case 'sms':
                return new SMSNotification();
            case 'push':
                return new PushNotification();
            default:
                throw new Error(`Unknown notification type: ${type}`);
        }
    }
}

// Usage
const notification = NotificationFactory.create('email');
notification.send('Hello!');

Singleton Pattern

Ensure only one instance exists:

class Configuration {
    private static instance: Configuration;
    private config: Map<string, string> = new Map();
    
    private constructor() {
        // Load configuration
        this.config.set('apiUrl', 'https://api.example.com');
        this.config.set('apiKey', 'secret-key');
    }
    
    static getInstance(): Configuration {
        if (!Configuration.instance) {
            Configuration.instance = new Configuration();
        }
        return Configuration.instance;
    }
    
    get(key: string): string | undefined {
        return this.config.get(key);
    }
    
    set(key: string, value: string): void {
        this.config.set(key, value);
    }
}

// Usage - always same instance
const config1 = Configuration.getInstance();
const config2 = Configuration.getInstance();

console.log(config1 === config2);  // true

config1.set('theme', 'dark');
console.log(config2.get('theme'));  // 'dark'

Observer Pattern

Subscribe to events:

interface Observer {
    update(event: string, data: any): void;
}

class EventEmitter {
    private observers = new Map<string, Observer[]>();
    
    subscribe(event: string, observer: Observer): void {
        if (!this.observers.has(event)) {
            this.observers.set(event, []);
        }
        this.observers.get(event)!.push(observer);
    }
    
    unsubscribe(event: string, observer: Observer): void {
        const observers = this.observers.get(event);
        if (observers) {
            const index = observers.indexOf(observer);
            if (index > -1) {
                observers.splice(index, 1);
            }
        }
    }
    
    emit(event: string, data: any): void {
        const observers = this.observers.get(event);
        if (observers) {
            observers.forEach(observer => observer.update(event, data));
        }
    }
}

class EmailObserver implements Observer {
    update(event: string, data: any): void {
        console.log(`Email notification: ${event}`, data);
    }
}

class LogObserver implements Observer {
    update(event: string, data: any): void {
        console.log(`Log: ${event}`, data);
    }
}

// Usage
const emitter = new EventEmitter();
const emailObserver = new EmailObserver();
const logObserver = new LogObserver();

emitter.subscribe('user.created', emailObserver);
emitter.subscribe('user.created', logObserver);

emitter.emit('user.created', { username: 'alice', email: '[email protected]' });
// Output:
// Email notification: user.created { username: 'alice', email: '[email protected]' }
// Log: user.created { username: 'alice', email: '[email protected]' }

Repository Pattern

Separate data access logic:

interface Repository<T> {
    findById(id: string): Promise<T | null>;
    findAll(): Promise<T[]>;
    save(entity: T): Promise<void>;
    delete(id: string): Promise<void>;
}

interface User {
    id: string;
    username: string;
    email: string;
}

class UserRepository implements Repository<User> {
    private users: Map<string, User> = new Map();
    
    async findById(id: string): Promise<User | null> {
        return this.users.get(id) || null;
    }
    
    async findAll(): Promise<User[]> {
        return Array.from(this.users.values());
    }
    
    async save(user: User): Promise<void> {
        this.users.set(user.id, user);
    }
    
    async delete(id: string): Promise<void> {
        this.users.delete(id);
    }
    
    async findByEmail(email: string): Promise<User | null> {
        const users = Array.from(this.users.values());
        return users.find(u => u.email === email) || null;
    }
}

// Usage
const userRepo = new UserRepository();

await userRepo.save({ id: '1', username: 'alice', email: '[email protected]' });
const user = await userRepo.findById('1');
console.log(user);

Decorator Pattern

Add behavior dynamically:

interface Coffee {
    cost(): number;
    description(): string;
}

class SimpleCoffee implements Coffee {
    cost(): number {
        return 5;
    }
    
    description(): string {
        return 'Simple coffee';
    }
}

// Decorators
class MilkDecorator implements Coffee {
    constructor(private coffee: Coffee) {}
    
    cost(): number {
        return this.coffee.cost() + 1;
    }
    
    description(): string {
        return `${this.coffee.description()}, milk`;
    }
}

class SugarDecorator implements Coffee {
    constructor(private coffee: Coffee) {}
    
    cost(): number {
        return this.coffee.cost() + 0.5;
    }
    
    description(): string {
        return `${this.coffee.description()}, sugar`;
    }
}

class WhipDecorator implements Coffee {
    constructor(private coffee: Coffee) {}
    
    cost(): number {
        return this.coffee.cost() + 2;
    }
    
    description(): string {
        return `${this.coffee.description()}, whip`;
    }
}

// Usage - compose decorators
let coffee: Coffee = new SimpleCoffee();
console.log(`${coffee.description()} = $${coffee.cost()}`);  // "Simple coffee = $5"

coffee = new MilkDecorator(coffee);
console.log(`${coffee.description()} = $${coffee.cost()}`);  // "Simple coffee, milk = $6"

coffee = new SugarDecorator(coffee);
console.log(`${coffee.description()} = $${coffee.cost()}`);  // "Simple coffee, milk, sugar = $6.5"

coffee = new WhipDecorator(coffee);
console.log(`${coffee.description()} = $${coffee.cost()}`);  // "Simple coffee, milk, sugar, whip = $8.5"

Best Practices

1. Apply SOLID from the Start

Start with good design, don't wait for refactoring.

2. Choose Right Pattern for Problem

Don't force patterns where they don't fit.

3. Keep It Simple

Don't over-engineer. Add complexity only when needed.

4. Test-Driven Design

If it's hard to test, the design needs improvement.

5. Refactor Continuously

Improve design as requirements evolve.

Conclusion

You've completed the OOP 101 series! You now understand:

Part 1: Classes, objects, constructors, methods, static members

Part 2: Encapsulation, access modifiers, getters/setters, information hiding

Part 3: Inheritance, polymorphism, abstract classes, method overriding

Part 4: Interfaces, composition, dependency injection, strategy pattern

Part 5: SOLID principles, essential design patterns, production-ready code

Next Steps

1. Practice SOLID: Refactor existing code using SOLID principles

2. Study More Patterns: Learn Command, Adapter, Proxy patterns

3. Build Projects: Apply OOP in real applications

4. Read Clean Code: Study "Clean Code" by Robert Martin

5. Domain-Driven Design: Explore DDD for complex domains

Resources

• Books:

  • "Design Patterns" by Gang of Four

  • "Clean Code" by Robert C. Martin

  • "Head First Design Patterns"

• Practice:

  • Refactoring.guru for design patterns

  • Code katas with OOP focus

  • Open source TypeScript projects

Keep coding, keep learning, and build maintainable systems!

---

Based on years of building production TypeScript applications, from monoliths to microservices, learning SOLID principles and design patterns through real-world experience.