Principio de Segregación de Interfaces (ISP) - TypeScript y React

Resumen: Domina el Principio de Segregación de Interfaces (ISP). Aprende conceptos SOLID con ejemplos prácticos en TypeScript y React para escribir código más limpio y mantenible.

Introducción

El Principio de Segregación de Interfaces (ISP) sostiene que ningún cliente debe verse forzado a depender de métodos que no utiliza. Aplicado correctamente, ISP reduce el acoplamiento, facilita las pruebas y hace que el código sea más fácil de cambiar y comprender. En esta guía verás ejemplos prácticos en TypeScript y React que puedes aplicar de inmediato para lograr una base de código más modular y mantenible. TypeScript es una de las opciones más populares en el desarrollo frontend moderno, lo que hace que aplicar ISP en proyectos React sea especialmente relevante⁶.

¿Qué es el Principio de Segregación de Interfaces?

Imagina un mando de TV con 90 botones cuando solo necesitas “Reproducir”. Esa frustración refleja el software cuando una clase implementa una interfaz grande y poco enfocada. ISP, la “I” de SOLID, fomenta diseñar interfaces pequeñas y específicas para cada cliente en lugar de contratos que lo abarquen todo. Evita el anti‑patrón de la “interfaz hinchada” y conduce a sistemas más claros y flexibles¹.

Por qué las interfaces hinchadas dañan

• Dependencias innecesarias: las clases se acoplan a métodos que no llaman, de modo que cambios no relacionados resultan arriesgados.
• Sobrecarga cognitiva: los desarrolladores deben escanear métodos irrelevantes para encontrar lo que necesitan.
• Implementaciones vacías: las clases implementan métodos no usados, añadiendo código repetitivo y frágil.

La idea central es simple: da a cada cliente exactamente lo que necesita, y nada más. Esto facilita entender, probar y evolucionar componentes.

Interfaces monolíticas vs. segregadas

Una comparación rápida muestra las ventajas de ISP.

Adoptar ISP mantiene la base de código adaptable conforme se añaden o refactorizan funciones.

ISP en la práctica: violaciones comunes

Las violaciones no suelen romper la aplicación inmediatamente, pero complican el mantenimiento. Busca clases con métodos vacíos o componentes con muchas props opcionales.

Una clásica “Interfaz Dios” en TypeScript

// ANTI-PATTERN: A "fat interface" that violates ISP
interface IUserActions {
  createUser(data: UserData): void;
  editUser(id: string, data: UserData): void;
  deleteUser(id: string): void;
  viewUserProfile(id: string): UserProfile;
  changeUserRole(id: string, newRole: Role): void;
  publishArticle(article: Article): void;
  approveComment(commentId: string): void;
}

Una clase Viewer forzada a implementar esto incluirá métodos sin sentido o que lanzan errores. Eso aumenta coste y riesgo en el mantenimiento.

Props infladas en componentes React

Un síntoma común en frontend es una Card genérica con muchas props opcionales. Eso crea ambigüedad sobre combinaciones válidas de props y obliga a renderizados condicionales complejos.

// ANTI-PATTERN: A bloated props interface
interface CardProps {
  title: string;
  description?: string;
  imageUrl?: string;
  imageAltText?: string;
  videoUrl?: string;
  authorName?: string;
  authorAvatarUrl?: string;
  publicationDate?: string;
  articleLink?: string;
  onClick?: () => void;
  // ... and many more optional props
}

Estos anti‑patrones preparan el terreno para refactorizaciones pequeñas y seguras.

Cómo refactorizar: de monolíticas a interfaces segregadas

Refactorizar hacia ISP no requiere reescrituras masivas. Aplica cambios incrementales para dividir responsabilidades y clarificar contratos.

1) Arreglando la “Interfaz Dios” en TypeScript

Paso A: identifica roles de cliente, por ejemplo: administradores, editores, visualizadores.

Paso B: crea interfaces específicas por rol.

// GOOD: Focused interfaces
interface IViewerActions {
  viewUserProfile(id: string): UserProfile;
}

interface IEditorActions {
  publishArticle(article: Article): void;
  approveComment(commentId: string): void;
}

interface IAdminActions {
  createUser(data: UserData): void;
  editUser(id: string, data: UserData): void;
  deleteUser(id: string): void;
  changeUserRole(id: string, newRole: Role): void;
}

Paso C: implementa solo lo que se necesita.

class Viewer implements IViewerActions {
  viewUserProfile(id: string): UserProfile {
    console.log(`Fetching profile for user ${id}...`);
    // ... fetch and return profile
  }
}

Un administrador puede implementar múltiples interfaces según sus responsabilidades. Esta separación reduce recompilaciones innecesarias y aclara quién posee cada capacidad.

2) Refactorizando props infladas de React con discriminated unions

Usa discriminated unions para que cada variante del componente tenga un contrato claro. Los tipos union y los discriminadores de TypeScript son ideales para esto².

// GOOD: Base props
type BaseCardProps = {
  title: string;
  onClick?: () => void;
};

// GOOD: Specific variants
type ImageCardProps = BaseCardProps & {
  cardType: 'image';
  imageUrl: string;
  imageAltText: string;
};

type ArticleCardProps = BaseCardProps & {
  cardType: 'article';
  description: string;
  authorName: string;
  articleLink: string;
};

type CardProps = ImageCardProps | ArticleCardProps;

Con este patrón, el compilador y el editor hacen cumplir combinaciones válidas de props y evitan permutaciones inválidas.

Auditar y aplicar ISP en tu equipo

Incorporar ISP en las prácticas del equipo aporta valor duradero. Combina criterios de auditoría claros con comprobaciones automatizadas para mantener las interfaces saludables.

Criterios de auditoría claros

Crea una lista para detectar violaciones de ISP durante las revisiones. Señales de alarma:

• Interfaces con muchos métodos (revisar cuando superen cinco a siete métodos).
• Métodos vacíos o stubbed en implementaciones.
• Nombres de interfaz vagos con palabras como “Manager” o “Handler”.
• Props de componentes con muchos campos opcionales.

Incluye estas comprobaciones en las revisiones y en la documentación interna, por ejemplo en /guides/solid-principles o en una guía de revisión de código en tu repo.

Automatizar la aplicación

ESLint y reglas personalizadas ayudan a capturar patrones evidentes, como props sobredimensionadas o clases que dejan métodos sin implementar³. Los asistentes de codificación basados en IA pueden señalar malos olores de diseño cuando se les pide revisar interfaces e implementaciones⁴.

La combinación de comprobaciones automáticas y revisiones humanas funciona mejor: las herramientas ofrecen consistencia y velocidad, y las personas capturan contexto e intención de negocio. Esto acelera ciclos Red‑Green‑Refactor y simplifica las pruebas unitarias, ya que las interfaces pequeñas son más fáciles de simular y comprobar⁵.

ISP y desarrollo impulsado por IA

A medida que la IA se integra más en los flujos de trabajo de desarrollo, las interfaces claras ayudan a que las herramientas razonen mejor sobre el código. Las interfaces pequeñas y enfocadas reducen la ambigüedad y mejoran la calidad del código generado, las sugerencias de refactorización y la documentación generada por herramientas como GitHub Copilot⁴.

Las interfaces limpias actúan como un brief preciso para humanos y máquinas, lo que reduce conjeturas y produce cambios asistidos por IA más fiables.

Preguntas frecuentes esenciales

¿Significa ISP que cada método necesita su propia interfaz?

No. El objetivo no es crear interfaces de un solo método por todas partes. Agrupa métodos que siempre se usan juntos por el mismo cliente. La meta son interfaces enfocadas y cohesivas, no fragmentación innecesaria.

¿En qué se diferencia ISP del Principio de Responsabilidad Única (SRP)?

SRP se aplica a clases y dice que una clase debe tener una única razón para cambiar. ISP se aplica a interfaces y dice que los clientes no deberían depender de métodos que no usan. Es posible cumplir SRP y aun así violar ISP si una clase implementa una interfaz hinchada.

¿Cuándo está bien ignorar ISP?

Principalmente cuando no puedes cambiar la interfaz: bibliotecas de terceros o APIs heredadas que no controlas. También cuando todos los clientes realmente necesitan todos los métodos, en cuyo caso una interfaz mayor puede seguir siendo cohesiva y aceptable.

Lista rápida de refactorización

• Identifica roles y clientes para cada interfaz.
• Divide interfaces grandes en contratos específicos por rol.
• Usa discriminated unions de TypeScript para variantes de props².
• Añade reglas de lint para marcar interfaces o props sobredimensionadas³.
• Combina comprobaciones automatizadas con revisión de código para decisiones matizadas.

Tres preguntas y respuestas concisas

Q: ¿Cómo detecto rápidamente una violación de ISP?

A: Busca interfaces con muchos métodos no relacionados, clases con métodos vacíos o que lanzan errores, y componentes con docenas de props opcionales. Son señales claras de que un contrato debe dividirse.

Q: ¿Cuál es la forma más rápida de arreglar una “interfaz hinchada”?

A: Identifica roles de cliente, crea interfaces específicas para cada rol y actualiza las implementaciones para que solo implementen lo que necesitan. Haz los cambios de forma incremental.

Q: ¿Cómo prevengo regresiones de ISP en una base de código en crecimiento?

A: Añade reglas de lint y comprobaciones en CI para detectar interfaces sobredimensionadas y añade una lista de verificación sobre diseño de interfaces en las revisiones de código. Combina automatización con auditorías manuales periódicas.

En Clean Code Guy, ayudamos a equipos a aplicar principios como ISP para construir bases de código mantenibles y listas para IA. Obtén una auditoría gratuita de tu base de código para encontrar problemas ocultos y mejorar la mantenibilidad a largo plazo.