SOLID Principles

Author: Htunn Thu Thu

Date: January 4, 2026

Tags: #SoftwareDesign #TypeScript #SOLID #BestPractices

Introduction

SOLID principles transformed how I write code. When I started building my MCP server for network security, I crammed everything into a single file. Authentication, port scanning, SSL validation—all tangled together. Adding a new feature meant touching dozens of lines, and bugs appeared in unexpected places.

After refactoring using SOLID principles, my codebase became modular, testable, and easy to extend. This guide shares what I learned applying these principles to real TypeScript projects.

What is SOLID?

SOLID is an acronym for five design principles that make software more maintainable:

• Single Responsibility Principle

• Open/Closed Principle

• Liskov Substitution Principle

• Interface Segregation Principle

• Dependency Inversion Principle

Let me show you how I applied each principle in my projects.

---

Single Responsibility Principle (SRP)

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

The Problem I Had

In my IoT monitoring platform, I initially created a monolithic SensorManager class:

// ❌ BAD: Violates SRP - too many responsibilities
class SensorManager {
  private sensors: Map<string, Sensor> = new Map();
  
  // Responsibility 1: Managing sensors
  addSensor(id: string, sensor: Sensor): void {
    this.sensors.set(id, sensor);
  }
  
  // Responsibility 2: Data persistence
  async saveToDB(sensor: Sensor): Promise<void> {
    await mongoClient.db('iot').collection('sensors').insertOne({
      id: sensor.id,
      data: sensor.data,
      timestamp: new Date()
    });
  }
  
  // Responsibility 3: Data formatting
  formatForDashboard(sensorId: string): string {
    const sensor = this.sensors.get(sensorId);
    return `Temperature: ${sensor.data.temp}°C, Humidity: ${sensor.data.humidity}%`;
  }
  
  // Responsibility 4: LLM query processing
  async queryWithLLM(question: string): Promise<string> {
    const context = Array.from(this.sensors.values())
      .map(s => this.formatForDashboard(s.id))
      .join('\n');
    
    return await this.llmService.query(question, context);
  }
}

This class had four reasons to change:

1. Sensor management logic changes

2. Database schema changes

3. Dashboard format changes

4. LLM integration changes

My Solution: Split Responsibilities

I refactored into focused classes:

// ✅ GOOD: Each class has a single responsibility

// Responsibility 1: Managing sensor collection
class SensorRegistry {
  private sensors: Map<string, Sensor> = new Map();
  
  add(id: string, sensor: Sensor): void {
    this.sensors.set(id, sensor);
  }
  
  get(id: string): Sensor | undefined {
    return this.sensors.get(id);
  }
  
  getAll(): Sensor[] {
    return Array.from(this.sensors.values());
  }
}

// Responsibility 2: Data persistence
class SensorRepository {
  constructor(private db: Db) {}
  
  async save(sensor: Sensor): Promise<void> {
    await this.db.collection('sensors').insertOne({
      id: sensor.id,
      data: sensor.data,
      timestamp: new Date()
    });
  }
  
  async findById(id: string): Promise<Sensor | null> {
    const doc = await this.db.collection('sensors').findOne({ id });
    return doc ? this.mapToSensor(doc) : null;
  }
  
  private mapToSensor(doc: any): Sensor {
    // Mapping logic
    return new Sensor(doc.id, doc.data);
  }
}

// Responsibility 3: Data formatting
class SensorFormatter {
  formatForDashboard(sensor: Sensor): string {
    return `Temperature: ${sensor.data.temp}°C, Humidity: ${sensor.data.humidity}%`;
  }
  
  formatForExport(sensor: Sensor): SensorExportData {
    return {
      sensorId: sensor.id,
      temperature: sensor.data.temp,
      humidity: sensor.data.humidity,
      timestamp: sensor.timestamp.toISOString()
    };
  }
}

// Responsibility 4: LLM integration
class SensorQueryService {
  constructor(
    private registry: SensorRegistry,
    private formatter: SensorFormatter,
    private llmService: LLMService
  ) {}
  
  async query(question: string): Promise<string> {
    const sensors = this.registry.getAll();
    const context = sensors
      .map(s => this.formatter.formatForDashboard(s))
      .join('\n');
    
    return await this.llmService.query(question, context);
  }
}

Benefits I Gained

• Easier testing: I could unit test SensorFormatter without needing a database or LLM

• Simpler changes: Updating the dashboard format only touched SensorFormatter

• Better reusability: I reused SensorRepository in other parts of my IoT platform

---

Open/Closed Principle (OCP)

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

The Problem I Had

In my Agentic LLM Search project, I needed to support multiple LLM providers:

// ❌ BAD: Adding new providers requires modifying this class
class LLMService {
  async query(prompt: string, provider: string): Promise<string> {
    if (provider === 'azure-openai') {
      const response = await fetch('https://api.openai.azure.com/...', {
        method: 'POST',
        headers: { 'api-key': process.env.AZURE_KEY },
        body: JSON.stringify({ prompt })
      });
      return await response.json();
    } else if (provider === 'local-tinyllama') {
      const response = await fetch('http://localhost:8000/generate', {
        method: 'POST',
        body: JSON.stringify({ prompt })
      });
      return await response.json();
    } else if (provider === 'anthropic') {
      // Another provider - modifying again!
      // ...
    }
    throw new Error('Unknown provider');
  }
}

Every new provider meant modifying LLMService, increasing the risk of breaking existing functionality.

My Solution: Plugin Architecture

I created an abstraction that allows extension without modification:

// ✅ GOOD: Open for extension, closed for modification

// Abstract interface
interface LLMProvider {
  readonly name: string;
  query(prompt: string, options?: LLMQueryOptions): Promise<string>;
}

// Azure OpenAI implementation
class AzureOpenAIProvider implements LLMProvider {
  readonly name = 'azure-openai';
  
  constructor(
    private apiKey: string,
    private endpoint: string
  ) {}
  
  async query(prompt: string, options?: LLMQueryOptions): Promise<string> {
    const response = await fetch(`${this.endpoint}/chat/completions`, {
      method: 'POST',
      headers: {
        'api-key': this.apiKey,
        'Content-Type': 'application/json'
      },
      body: JSON.stringify({
        messages: [{ role: 'user', content: prompt }],
        temperature: options?.temperature ?? 0.7,
        max_tokens: options?.maxTokens ?? 1000
      })
    });
    
    const data = await response.json();
    return data.choices[0].message.content;
  }
}

// Local LLM implementation
class LocalLLMProvider implements LLMProvider {
  readonly name = 'local-tinyllama';
  
  constructor(private endpoint: string = 'http://localhost:8000') {}
  
  async query(prompt: string, options?: LLMQueryOptions): Promise<string> {
    const response = await fetch(`${this.endpoint}/generate`, {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({
        prompt,
        temperature: options?.temperature ?? 0.7,
        max_length: options?.maxTokens ?? 1000
      })
    });
    
    const data = await response.json();
    return data.generated_text;
  }
}

// Service that works with any provider
class LLMService {
  private providers: Map<string, LLMProvider> = new Map();
  
  registerProvider(provider: LLMProvider): void {
    this.providers.set(provider.name, provider);
  }
  
  async query(
    prompt: string, 
    providerName: string, 
    options?: LLMQueryOptions
  ): Promise<string> {
    const provider = this.providers.get(providerName);
    if (!provider) {
      throw new Error(`Provider '${providerName}' not registered`);
    }
    
    return await provider.query(prompt, options);
  }
}

// Usage - adding new providers doesn't modify LLMService
const llmService = new LLMService();
llmService.registerProvider(new AzureOpenAIProvider(
  process.env.AZURE_KEY!,
  process.env.AZURE_ENDPOINT!
));
llmService.registerProvider(new LocalLLMProvider());

// Easy to add new providers later without changing existing code
class AnthropicProvider implements LLMProvider {
  readonly name = 'anthropic';
  // Implementation...
  async query(prompt: string): Promise<string> {
    // Anthropic-specific logic
    return '';
  }
}
llmService.registerProvider(new AnthropicProvider());

Benefits I Gained

• Zero risk to existing code: Adding Anthropic support didn't touch Azure or local providers

• Easy testing: I created a MockLLMProvider for tests in seconds

• Flexible deployment: Different environments use different providers without code changes

---

Liskov Substitution Principle (LSP)

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

The Problem I Had

In my MCP server, I created a hierarchy for different scan types:

// ❌ BAD: Violates LSP - not all scans can timeout

class NetworkScan {
  constructor(protected host: string) {}
  
  async execute(timeout: number): Promise<ScanResult> {
    // Base implementation
    throw new Error('Must implement');
  }
}

class PortScan extends NetworkScan {
  async execute(timeout: number): Promise<ScanResult> {
    // Works fine with timeout
    const controller = new AbortController();
    const timeoutId = setTimeout(() => controller.abort(), timeout);
    
    try {
      const result = await this.scanPort(controller.signal);
      return result;
    } finally {
      clearTimeout(timeoutId);
    }
  }
  
  private async scanPort(signal: AbortSignal): Promise<ScanResult> {
    // Actual port scanning logic
    return { open: true, port: 443 };
  }
}

class DNSLookup extends NetworkScan {
  async execute(timeout: number): Promise<ScanResult> {
    // ❌ Problem: DNS lookups don't support timeout in my implementation
    // Ignoring the timeout parameter breaks LSP!
    const result = await dns.lookup(this.host);
    return { ip: result.address };
  }
}

// This breaks when using DNSLookup through NetworkScan interface
async function runScan(scan: NetworkScan): Promise<ScanResult> {
  // Expects timeout to work, but doesn't for DNSLookup!
  return await scan.execute(5000);
}

My Solution: Proper Abstraction

I redesigned the hierarchy to ensure substitutability:

// ✅ GOOD: All implementations honor the contract

interface ScanOptions {
  timeout?: number;
  retries?: number;
}

// Base class with proper abstraction
abstract class NetworkScan {
  constructor(protected host: string) {}
  
  async execute(options: ScanOptions = {}): Promise<ScanResult> {
    const timeout = options.timeout ?? 5000;
    
    return await this.executeWithTimeout(timeout);
  }
  
  private async executeWithTimeout(timeout: number): Promise<ScanResult> {
    const controller = new AbortController();
    const timeoutId = setTimeout(() => controller.abort(), timeout);
    
    try {
      return await this.performScan(controller.signal);
    } catch (error) {
      if (error.name === 'AbortError') {
        throw new Error(`Scan timed out after ${timeout}ms`);
      }
      throw error;
    } finally {
      clearTimeout(timeoutId);
    }
  }
  
  // Each subclass must implement this properly
  protected abstract performScan(signal: AbortSignal): Promise<ScanResult>;
}

class PortScan extends NetworkScan {
  constructor(host: string, private port: number) {
    super(host);
  }
  
  protected async performScan(signal: AbortSignal): Promise<ScanResult> {
    const socket = new net.Socket();
    
    return new Promise((resolve, reject) => {
      signal.addEventListener('abort', () => {
        socket.destroy();
        reject(new Error('AbortError'));
      });
      
      socket.connect(this.port, this.host, () => {
        socket.destroy();
        resolve({ open: true, port: this.port });
      });
      
      socket.on('error', () => {
        resolve({ open: false, port: this.port });
      });
    });
  }
}

class DNSLookup extends NetworkScan {
  protected async performScan(signal: AbortSignal): Promise<ScanResult> {
    // Now properly respects abort signal
    return new Promise((resolve, reject) => {
      signal.addEventListener('abort', () => {
        reject(new Error('AbortError'));
      });
      
      dns.lookup(this.host, (err, address) => {
        if (err) reject(err);
        else resolve({ ip: address, host: this.host });
      });
    });
  }
}

// Now works correctly with any NetworkScan subclass
async function runScan(scan: NetworkScan, timeout: number): Promise<ScanResult> {
  // All subclasses honor the timeout properly
  return await scan.execute({ timeout });
}

// Both work as expected
const portScan = new PortScan('example.com', 443);
const dnsLookup = new DNSLookup('example.com');

await runScan(portScan, 3000);  // ✅ Respects timeout
await runScan(dnsLookup, 3000); // ✅ Also respects timeout

Benefits I Gained

• Predictable behavior: Any NetworkScan subclass can be used interchangeably

• Maintainable hierarchy: Adding new scan types follows clear rules

• Better testing: Mock scans work exactly like real ones

---

Interface Segregation Principle (ISP)

Clients should not be forced to depend on interfaces they don't use.

The Problem I Had

In my IoT platform, I created a fat interface for all sensor operations:

// ❌ BAD: Fat interface forces unnecessary dependencies

interface Sensor {
  // Basic operations
  getId(): string;
  getData(): SensorData;
  
  // Storage operations
  saveToDB(): Promise<void>;
  loadFromDB(): Promise<void>;
  
  // Export operations
  exportToCSV(): Promise<string>;
  exportToJSON(): Promise<string>;
  
  // Visualization
  renderChart(): ChartData;
  renderTable(): TableData;
  
  // LLM operations
  generateDescription(): Promise<string>;
  answerQuestion(question: string): Promise<string>;
}

// Problem: Simple temperature sensor doesn't need all this!
class TemperatureSensor implements Sensor {
  getId(): string { return this.id; }
  getData(): SensorData { return this.data; }
  
  // ❌ Forced to implement things I don't need
  saveToDB(): Promise<void> { 
    throw new Error('Not supported'); 
  }
  loadFromDB(): Promise<void> { 
    throw new Error('Not supported'); 
  }
  exportToCSV(): Promise<string> { 
    throw new Error('Not supported'); 
  }
  // ... many more methods I don't want!
}

My Solution: Focused Interfaces

I split the fat interface into smaller, focused ones:

// ✅ GOOD: Small, focused interfaces

// Core sensor behavior
interface ISensor {
  getId(): string;
  getData(): SensorData;
}

// Optional: Data persistence
interface IPersistable {
  saveToDB(): Promise<void>;
  loadFromDB(): Promise<void>;
}

// Optional: Data export
interface IExportable {
  exportToCSV(): Promise<string>;
  exportToJSON(): Promise<string>;
}

// Optional: Visualization
interface IVisualizable {
  renderChart(): ChartData;
  renderTable(): TableData;
}

// Optional: AI capabilities
interface IAIEnabled {
  generateDescription(): Promise<string>;
  answerQuestion(question: string): Promise<string>;
}

// Simple sensor only implements what it needs
class TemperatureSensor implements ISensor {
  constructor(
    private id: string,
    private data: SensorData
  ) {}
  
  getId(): string {
    return this.id;
  }
  
  getData(): SensorData {
    return this.data;
  }
}

// Smart sensor implements multiple interfaces
class SmartIoTSensor implements ISensor, IPersistable, IExportable, IAIEnabled {
  constructor(
    private id: string,
    private data: SensorData,
    private repository: SensorRepository,
    private llmService: LLMService
  ) {}
  
  // ISensor
  getId(): string { return this.id; }
  getData(): SensorData { return this.data; }
  
  // IPersistable
  async saveToDB(): Promise<void> {
    await this.repository.save(this);
  }
  
  async loadFromDB(): Promise<void> {
    const data = await this.repository.findById(this.id);
    if (data) this.data = data;
  }
  
  // IExportable
  async exportToCSV(): Promise<string> {
    return `${this.id},${this.data.temp},${this.data.humidity}`;
  }
  
  async exportToJSON(): Promise<string> {
    return JSON.stringify({ id: this.id, data: this.data });
  }
  
  // IAIEnabled
  async generateDescription(): Promise<string> {
    return await this.llmService.query(
      `Describe this sensor data: ${JSON.stringify(this.data)}`
    );
  }
  
  async answerQuestion(question: string): Promise<string> {
    return await this.llmService.query(
      `${question}\nContext: ${JSON.stringify(this.data)}`
    );
  }
}

// Functions work with specific interfaces they need
function displaySensor(sensor: ISensor): void {
  console.log(`Sensor ${sensor.getId()}: ${JSON.stringify(sensor.getData())}`);
}

function exportData(exportable: IExportable): Promise<string> {
  return exportable.exportToCSV();
}

// Usage
const simple = new TemperatureSensor('temp-01', { temp: 22, humidity: 45 });
displaySensor(simple); // ✅ Works

const smart = new SmartIoTSensor('smart-01', { temp: 23, humidity: 50 }, repo, llm);
displaySensor(smart);  // ✅ Works
await exportData(smart); // ✅ Works - smart sensor supports export

Benefits I Gained

• Simpler implementations: Basic sensors don't carry unnecessary baggage

• Flexible composition: Services depend only on interfaces they actually use

• Easier testing: Mock only the interfaces you need for each test

---

Dependency Inversion Principle (DIP)

Depend on abstractions, not concretions. High-level modules should not depend on low-level modules.

The Problem I Had

My MCP server initially had tight coupling:

// ❌ BAD: High-level module depends on low-level details

class PortCheckerTool {
  // Tightly coupled to specific implementation
  private scanner = new NmapScanner();
  
  async checkPort(host: string, port: number): Promise<boolean> {
    // Directly using concrete class
    const result = await this.scanner.scan(host, port);
    return result.isOpen;
  }
}

class NmapScanner {
  async scan(host: string, port: number): Promise<{ isOpen: boolean }> {
    // Nmap-specific implementation
    const output = await exec(`nmap -p ${port} ${host}`);
    return { isOpen: output.includes('open') };
  }
}

// Problems:
// - Can't test PortCheckerTool without running nmap
// - Can't switch to different scanner without modifying PortCheckerTool
// - Hard to use in environments where nmap isn't available

My Solution: Dependency Injection

I inverted the dependency by depending on abstractions:

// ✅ GOOD: Depend on abstractions

// High-level abstraction
interface IPortScanner {
  scan(host: string, port: number): Promise<ScanResult>;
}

interface ScanResult {
  host: string;
  port: number;
  isOpen: boolean;
  service?: string;
}

// Low-level implementation 1: Nmap
class NmapScanner implements IPortScanner {
  async scan(host: string, port: number): Promise<ScanResult> {
    const output = await exec(`nmap -p ${port} ${host}`);
    const isOpen = output.includes('open');
    const service = this.extractService(output);
    
    return { host, port, isOpen, service };
  }
  
  private extractService(output: string): string | undefined {
    const match = output.match(/(\d+)\/tcp\s+open\s+(\w+)/);
    return match ? match[2] : undefined;
  }
}

// Low-level implementation 2: Native Node.js
class NodePortScanner implements IPortScanner {
  async scan(host: string, port: number): Promise<ScanResult> {
    return new Promise((resolve) => {
      const socket = new net.Socket();
      
      socket.setTimeout(2000);
      
      socket.on('connect', () => {
        socket.destroy();
        resolve({ host, port, isOpen: true });
      });
      
      socket.on('timeout', () => {
        socket.destroy();
        resolve({ host, port, isOpen: false });
      });
      
      socket.on('error', () => {
        resolve({ host, port, isOpen: false });
      });
      
      socket.connect(port, host);
    });
  }
}

// High-level module depends on abstraction
class PortCheckerTool {
  constructor(private scanner: IPortScanner) {} // Dependency injection
  
  async checkPort(host: string, port: number): Promise<boolean> {
    const result = await this.scanner.scan(host, port);
    return result.isOpen;
  }
  
  async checkMultiplePorts(
    host: string, 
    ports: number[]
  ): Promise<Map<number, boolean>> {
    const results = new Map<number, boolean>();
    
    for (const port of ports) {
      const result = await this.scanner.scan(host, port);
      results.set(port, result.isOpen);
    }
    
    return results;
  }
}

// Composition root - wire up dependencies
class MCPServerFactory {
  createPortChecker(config: Config): PortCheckerTool {
    // Choose implementation based on environment
    const scanner: IPortScanner = config.useNmap 
      ? new NmapScanner()
      : new NodePortScanner();
    
    return new PortCheckerTool(scanner);
  }
}

// Usage in production
const factory = new MCPServerFactory();
const portChecker = factory.createPortChecker({ useNmap: false });
await portChecker.checkPort('example.com', 443);

// Easy testing with mock
class MockScanner implements IPortScanner {
  constructor(private mockResults: Map<number, boolean>) {}
  
  async scan(host: string, port: number): Promise<ScanResult> {
    const isOpen = this.mockResults.get(port) ?? false;
    return { host, port, isOpen };
  }
}

// Test
const mockResults = new Map([[443, true], [80, false]]);
const testChecker = new PortCheckerTool(new MockScanner(mockResults));
const is443Open = await testChecker.checkPort('test.com', 443);
console.assert(is443Open === true); // ✅ Easy to test

Benefits I Gained

• Testability: I can inject mock scanners for unit tests

• Flexibility: Switch between Nmap and native scanning without changing PortCheckerTool

• Environment adaptation: Use different implementations in Docker vs local development

---

Real-World Application: Refactoring My MCP Server

Here's how I applied all SOLID principles together when refactoring my SimplePortChecker MCP:

// Complete example showing all SOLID principles

// ISP: Focused interfaces
interface ITool {
  name: string;
  description: string;
  execute(params: ToolParams): Promise<ToolResult>;
}

interface IValidator {
  validate(params: ToolParams): ValidationResult;
}

// DIP: Abstract dependencies
interface ILogger {
  info(message: string): void;
  error(message: string, error: Error): void;
}

// SRP: Single responsibility classes
class PortScanValidator implements IValidator {
  validate(params: ToolParams): ValidationResult {
    if (!params.host) {
      return { valid: false, error: 'Host is required' };
    }
    if (!params.port || params.port < 1 || params.port > 65535) {
      return { valid: false, error: 'Port must be between 1 and 65535' };
    }
    return { valid: true };
  }
}

// SRP: Logging responsibility
class ConsoleLogger implements ILogger {
  info(message: string): void {
    console.log(`[INFO] ${new Date().toISOString()} - ${message}`);
  }
  
  error(message: string, error: Error): void {
    console.error(`[ERROR] ${new Date().toISOString()} - ${message}`, error);
  }
}

// LSP: Proper base class
abstract class BaseTool implements ITool {
  constructor(
    public readonly name: string,
    public readonly description: string,
    protected logger: ILogger,
    protected validator: IValidator
  ) {}
  
  async execute(params: ToolParams): Promise<ToolResult> {
    // Template method pattern ensuring all tools behave consistently
    const validation = this.validator.validate(params);
    if (!validation.valid) {
      this.logger.error(`Validation failed for ${this.name}`, new Error(validation.error));
      return { success: false, error: validation.error };
    }
    
    try {
      this.logger.info(`Executing ${this.name} with params: ${JSON.stringify(params)}`);
      return await this.performOperation(params);
    } catch (error) {
      this.logger.error(`Error in ${this.name}`, error as Error);
      return { success: false, error: (error as Error).message };
    }
  }
  
  protected abstract performOperation(params: ToolParams): Promise<ToolResult>;
}

// OCP: New tools extend without modifying base
class PortScanTool extends BaseTool {
  constructor(
    private scanner: IPortScanner,
    logger: ILogger,
    validator: IValidator
  ) {
    super('port_scan', 'Scan a port on a host', logger, validator);
  }
  
  protected async performOperation(params: ToolParams): Promise<ToolResult> {
    const result = await this.scanner.scan(params.host, params.port);
    return {
      success: true,
      data: {
        host: result.host,
        port: result.port,
        open: result.isOpen,
        service: result.service
      }
    };
  }
}

class SSLCheckTool extends BaseTool {
  constructor(
    private sslChecker: ISSLChecker,
    logger: ILogger,
    validator: IValidator
  ) {
    super('ssl_check', 'Check SSL certificate', logger, validator);
  }
  
  protected async performOperation(params: ToolParams): Promise<ToolResult> {
    const cert = await this.sslChecker.getCertificate(params.host);
    return {
      success: true,
      data: {
        issuer: cert.issuer,
        validFrom: cert.validFrom,
        validTo: cert.validTo,
        daysUntilExpiry: cert.daysUntilExpiry
      }
    };
  }
}

// Composition root
class MCPServer {
  private tools: Map<string, ITool> = new Map();
  
  constructor(private logger: ILogger) {}
  
  registerTool(tool: ITool): void {
    this.tools.set(tool.name, tool);
    this.logger.info(`Registered tool: ${tool.name}`);
  }
  
  async executeTool(name: string, params: ToolParams): Promise<ToolResult> {
    const tool = this.tools.get(name);
    if (!tool) {
      return { success: false, error: `Unknown tool: ${name}` };
    }
    
    return await tool.execute(params);
  }
}

// Bootstrap
const logger = new ConsoleLogger();
const portValidator = new PortScanValidator();
const scanner = new NodePortScanner();
const sslChecker = new NativeSSLChecker();

const server = new MCPServer(logger);
server.registerTool(new PortScanTool(scanner, logger, portValidator));
server.registerTool(new SSLCheckTool(sslChecker, logger, new SSLValidator()));

// Usage
await server.executeTool('port_scan', { host: 'example.com', port: 443 });

---

Common Mistakes I Made

Mistake 1: Over-Engineering

Early on, I applied SOLID too zealously and created unnecessary abstractions. Not every class needs an interface—only create them when you genuinely need flexibility or testability.

Rule of thumb I follow: Create abstraction when you have (or foresee) multiple implementations, not "just in case."

Mistake 2: Forgetting the "Why"

I sometimes created single-method interfaces thinking I was following ISP, but they added complexity without value. Interfaces should represent meaningful contracts, not just split methods arbitrarily.

Mistake 3: Incomplete LSP

I had subclasses that threw "Not Supported" exceptions for inherited methods. This violated LSP. Better to rethink the hierarchy or use composition instead.

---

Practical Tips

When to Apply SOLID

✅ Apply when:

• Building reusable libraries or frameworks

• Code will be maintained by multiple people

• Requirements are likely to change

• You need comprehensive testing

⚠️ Be pragmatic when:

• Writing scripts or prototypes

• Deadlines are tight (but plan to refactor)

• The code is genuinely simple and unlikely to change

My Workflow

1. Write it working first: I get the feature working, even if messy

2. Identify pain points: Where is it hard to test or extend?

3. Apply SOLID selectively: Refactor the painful parts

4. Test the refactoring: Ensure behavior didn't change

5. Document decisions: Note why I chose certain patterns

---

Conclusion

SOLID principles aren't academic rules—they're practical guidelines I use daily. They've made my TypeScript projects:

• Easier to test: Dependency injection enables comprehensive unit testing

• Faster to modify: New features don't require rewriting existing code

• More reliable: Changes in one area don't break unrelated functionality

• Better documented: Code structure itself communicates intent

The key is applying them pragmatically. Start with SRP and DIP—they provide the most value. Add the others as complexity grows.

What's Next?

Now that you understand SOLID, explore how these principles apply to design patterns:

• Design Principles (DRY, KISS, YAGNI) →

• Creational Design Patterns →

• Component Design & Modularity →

References

• My SimplePortChecker MCP Server - SOLID in practice

• Refactoring.Guru - SOLID

• TypeScript Handbook - Interfaces

---

Previous: ← Software Design 101 | Next: Design Principles →