Software Architecture

Single Responsibility

A class should have one, and only one, reason to change. Each class should focus on a single task or responsibility.

Benefits

• Easier to test
• Easier to maintain
• Easier to understand
• Reduces coupling

Code Example

// Bad ❌
class User {
  saveToDatabase() { }
  sendEmail() { }
  generateReport() { }
}
// Good ✅
class User {
  constructor(data) { }
}
class UserRepository {
  save(user) { }
}
class EmailService {
  send(user, message) { }
}
class ReportGenerator {
  generate(user) { }
}

Open/Closed

Software entities should be open for extension but closed for modification. Add new functionality without changing existing code.

Benefits

• Flexible code
• Easy to extend
• Minimal risk when adding features
• Promotes reusability

Code Example

// Bad ❌
class AreaCalculator {
  calculate(shape) {
    if (shape.type === 'circle') {
      return Math.PI * shape.radius ** 2;
    }
    if (shape.type === 'rectangle') {
      return shape.width * shape.height;
    }
  }
}

// Good ✅
interface Shape {
  calculateArea(): number;
}
class Circle implements Shape {
  calculateArea() {
    return Math.PI * this.radius ** 2;
  }
}
class Rectangle implements Shape {
  calculateArea() {
    return this.width * this.height;
  }
}

Liskov Substitution

Objects of a superclass should be replaceable with objects of its subclasses without breaking the application.

Benefits

• Predictable behavior
• Correct inheritance
• Type safety
• Reliable polymorphism

Code Example

// Bad ❌
class Bird {
  fly() { }
}
class Penguin extends Bird {
  fly() {
    throw new Error("Can't fly!");
  }
}

// Good ✅
class Bird {
  move() { }
}
class FlyingBird extends Bird {
  fly() { }
}
class Penguin extends Bird {
  swim() { }
}

Interface Segregation

Clients should not be forced to depend on interfaces they do not use. Split large interfaces into smaller, specific ones.

Benefits

• Flexible interfaces
• No unnecessary methods
• Better code organization
• Easier to implement

Code Example

// Bad ❌
interface Worker {
  work(): void;
  eat(): void;
  sleep(): void;
}
class Robot implements Worker {
  work() { }
  eat() { /* Robot doesn't eat! */ }
  sleep() { /* Robot doesn't sleep! */ }
}

// Good ✅
interface Workable { work(): void; }
interface Eatable { eat(): void; }
interface Sleepable { sleep(): void; }
class Robot implements Workable {
  work() { }
}

Dependency Inversion

High-level modules should not depend on low-level modules. Both should depend on abstractions.

Benefits

• Flexible architecture
• Easy to swap implementations
• Better testability
• Reduced coupling

Code Example

// Bad ❌
class MySQLDatabase {
  save(data) { }
}
class UserService {
  constructor() {
    this.db = new MySQLDatabase();
  }
}

// Good ✅
interface Database { save(data): void; }
class MySQLDatabase implements Database {
  save(data) { }
}
class UserService {
  constructor(private db: Database) { }
}