Segregación de interfaces (ISP)

¿Qué es?

El Interface Segregation Principle dice que es mejor tener varias interfaces pequeñas y específicas que una sola interfaz "gorda" con métodos que no todos los implementadores necesitan. Una interfaz demasiado grande obliga a las clases a implementar (o simular) comportamiento que no les corresponde.

Antes: una interfaz que no le sirve a todos

interface Worker {
  work(): void;
  eat(): void;
}

class HumanWorker implements Worker {
  work(): void {
    console.log('Trabajando...');
  }

  eat(): void {
    console.log('Almorzando...');
  }
}

// Un robot no come, pero la interfaz lo obliga a implementar eat()
class RobotWorker implements Worker {
  work(): void {
    console.log('Ejecutando tareas...');
  }

  eat(): void {
    throw new Error('Los robots no comen');
  }
}

RobotWorker se ve forzado a implementar eat() aunque no tiene sentido para él, terminando en un método que solo lanza un error. Cualquier código que reciba un Worker genérico y llame a eat() puede romperse en tiempo de ejecución.

Después: interfaces pequeñas y específicas

interface Workable {
  work(): void;
}

interface Eatable {
  eat(): void;
}

class HumanWorker implements Workable, Eatable {
  work(): void {
    console.log('Trabajando...');
  }

  eat(): void {
    console.log('Almorzando...');
  }
}

// El robot solo implementa lo que realmente necesita
class RobotWorker implements Workable {
  work(): void {
    console.log('Ejecutando tareas...');
  }
}

function makeWork(worker: Workable) {
  worker.work();
}

Al dividir Worker en Workable y Eatable, cada clase implementa solo las capacidades que efectivamente tiene, y el código que solo necesita hacer trabajar a alguien depende únicamente de Workable.

A tener en cuenta: ISP suele ir de la mano con OCP y DIP: interfaces chicas y enfocadas son más fáciles de extender y de sustituir por implementaciones alternativas.