Explain the SOLID principles in software design. Why are they important, and can you give a practical example of how violating one of these principles creates problems?

Question

Accepted Answer

## What Are the SOLID Principles?

SOLID is an acronym for five design principles that help create maintainable, flexible, and scalable software. These principles were promoted by Robert C. Martin, also known as Uncle Bob.

## The Five Principles

### S - Single Responsibility Principle

A class should have only one reason to change. Each class or module should focus on a single responsibility.

**Violation Example:**
```javascript
class UserService {
  createUser(data) { /* ... */ }
  sendWelcomeEmail(user) { /* ... */ }
  generatePdfReport(user) { /* ... */ }
  logUserActivity(user) { /* ... */ }
}
```

This class handles user creation, email sending, PDF generation, and logging. Any change to email templates, report formats, or logging could require modifying this class.

**Correct Approach:**
```javascript
class UserService { createUser(data) { /* ... */ } }
class EmailService { sendWelcomeEmail(user) { /* ... */ } }
class ReportService { generatePdfReport(user) { /* ... */ } }
class ActivityLogger { logUserActivity(user) { /* ... */ } }
```

### O - Open/Closed Principle

Software entities should be open for extension but closed for modification. You should be able to add new functionality without changing existing code.

**Violation Example:**
```javascript
function calculateDiscount(customer) {
  if (customer.type === 'regular') return 0.1;
  if (customer.type === 'premium') return 0.2;
  if (customer.type === 'vip') return 0.3;
  // Adding new customer types requires modifying this function
}
```

**Correct Approach:**
```javascript
const discountStrategies = {
  regular: () => 0.1,
  premium: () => 0.2,
  vip: () => 0.3
};

function calculateDiscount(customer) {
  return discountStrategies[customer.type]?.() || 0;
}
// Adding new types: just add to the strategies object
```

### L - Liskov Substitution Principle

Objects of a superclass should be replaceable with objects of a subclass without breaking the application. Subclasses must honor the contract established by the parent class.

**Violation Example:**
```javascript
class Bird {
  fly() { console.log('Flying'); }
}

class Penguin extends Bird {
  fly() { throw new Error('Penguins cannot fly'); }
}
// Code expecting a Bird will break with a Penguin
```

**Correct Approach:**
```javascript
class Bird { }
class FlyingBird extends Bird {
  fly() { console.log('Flying'); }
}
class Penguin extends Bird {
  swim() { console.log('Swimming'); }
}
```

### I - Interface Segregation Principle

Clients should not be forced to depend on interfaces they don't use. Prefer many specific interfaces over one general-purpose interface.

**Violation Example:**
```javascript
interface Worker {
  work(): void;
  eat(): void;
  sleep(): void;
}

class Robot implements Worker {
  work() { /* ... */ }
  eat() { throw new Error('Robots do not eat'); }
  sleep() { throw new Error('Robots do not sleep'); }
}
```

**Correct Approach:**
```javascript
interface Workable { work(): void; }
interface Eatable { eat(): void; }
interface Sleepable { sleep(): void; }

class Human implements Workable, Eatable, Sleepable { /* ... */ }
class Robot implements Workable { /* ... */ }
```

### D - Dependency Inversion Principle

High-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend on details. Details should depend on abstractions.

**Violation Example:**
```javascript
class OrderService {
  private database = new MySQLDatabase();

  saveOrder(order) {
    this.database.insert('orders', order);
  }
}
// Changing to PostgreSQL requires modifying OrderService
```

**Correct Approach:**
```javascript
interface Database {
  insert(table: string, data: any): void;
}

class OrderService {
  constructor(private database: Database) { }

  saveOrder(order) {
    this.database.insert('orders', order);
  }
}
// Can inject any database implementation
```

## Why SOLID Matters

| Principle | Benefit |
|-----------|---------|
| Single Responsibility | Easier to understand, test, and modify |
| Open/Closed | Add features without breaking existing code |
| Liskov Substitution | Reliable polymorphism and inheritance |
| Interface Segregation | Cleaner, more focused dependencies |
| Dependency Inversion | Loose coupling, easier testing |

Following SOLID principles makes code more maintainable, testable, and adaptable to change. In large systems, these principles prevent the codebase from becoming a tangled mess where every change risks breaking something else.