Principio de segregación de interfaz

En el campo de la ingeniería de software , el principio de segregación de interfaz ( ISP ) establece que ningún código debe verse obligado a depender de métodos que no utiliza. ^[1] ISP divide las interfaces que son muy grandes en interfaces más pequeñas y específicas para que los clientes solo tengan que conocer los métodos que les interesan. Estas interfaces reducidas también se denominan interfaces de rol . ^[2] ISP tiene como objetivo mantener un sistema desacoplado y, por lo tanto, más fácil de refactorizar, cambiar y reimplementar. ISP es uno de los cinco principios SOLID del diseño orientado a objetos, similar al Principio de alta cohesión de GRASP . ^[3] Más allá del diseño orientado a objetos, ISP también es un principio clave en el diseño de sistemas distribuidos en general y uno de los seis principios IDEALS para el diseño de microservicios . ^[4]

En el diseño orientado a objetos , las interfaces proporcionan capas de abstracción que simplifican el código y crean una barrera que impide el acoplamiento con dependencias . Un sistema puede llegar a estar tan acoplado en múltiples niveles que ya no sea posible realizar un cambio en un lugar sin necesitar muchos cambios adicionales. ^[1] El uso de una interfaz o una clase abstracta puede evitar este efecto secundario.

El ISP fue utilizado y formulado por primera vez por Robert C. Martin ^[5] mientras trabajaba como consultor para Xerox . Xerox había creado un nuevo sistema de impresión que podía realizar una variedad de tareas, como grapar y enviar faxes. El software para este sistema se creó desde cero. A medida que el software crecía, realizar modificaciones se volvió cada vez más difícil, de modo que incluso el cambio más pequeño requería un ciclo de reimplementación de una hora, lo que hacía que el desarrollo fuera casi imposible.

El problema de diseño era que casi todas las tareas utilizaban una única clase Job. Siempre que era necesario realizar un trabajo de impresión o de grapado, se realizaba una llamada a la clase Job. Esto daba como resultado una clase "gruesa" con multitud de métodos específicos para una variedad de clientes diferentes. Debido a este diseño, un trabajo de grapado conocería todos los métodos del trabajo de impresión, aunque no tuvieran ningún uso.

La solución sugerida por Martin utilizó lo que hoy se denomina el Principio de segregación de interfaz. Aplicado al software de Xerox, se agregó una capa de interfaz entre la clase Job y sus clientes utilizando el Principio de inversión de dependencia . En lugar de tener una gran clase Job, se creó una interfaz Staple Job o una interfaz Print Job que serían utilizadas por las clases Staple o Print, respectivamente, invocando métodos de la clase Job. Por lo tanto, se creó una interfaz para cada tipo de trabajo, que fue implementada por la clase Job.

Una violación típica del principio de segregación de interfaz se da en Desarrollo de software ágil: principios, patrones y prácticas ^[1] en 'Ejemplo de transacción de cajero automático' y en un artículo también escrito por Robert C. Martin específicamente sobre el ISP. ^[6] Este ejemplo analiza la interfaz de usuario para un cajero automático, que maneja todas las solicitudes, como una solicitud de depósito o una solicitud de retiro, y cómo esta interfaz debe segregarse en interfaces individuales y más específicas.

• SOLID – la "I" en SOLID significa principio de segregación de interfaz

• Principios de OOD: descripción y enlaces a artículos detallados sobre SOLID.