Errores comunes al diseñar Interfaces – #SOLID – ISP

El Principio de Segregación de Interfaces (ISP) esconde unos matices muy sutiles que pueden pasar desapercibidos. No obstante, estos matices a la hora de interpretar el ISP son sumamente importantes ya que ayudarán a un correcto diseño de nuestras interfaces y, por tanto, de nuestra aplicación.

En este vídeo veremos principalmente en qué se basa el concepto “las interfaces pertenecen a los clientes que las usan y no a las clases que las implementan“. También hablaremos del “acoplamiento estructural” de nuestras interfaces.

Recomiendo darle un voto de confianza a la explicación. Al principio del vídeo creo que me lío un poco y a medida que avanza el vídeo considero que se puede entender mejor lo que quiero transmitir.

Gracias a Armando Antón por el comentario en el vídeo anterior que ha hecho que me replantee cómo entendía el ISP 😀 !

Perdón por el retraso en la publicación de este vídeo. He tenido algunos problemas con el iMovie a la hora de subir el vídeo a YouTube :-/
La semana que viene no habrá vídeo. Nos vemos la siguiente (jueves 21)!

SHOWHIDE Comments (4)
  1. Hola
    Me gustó el video.
    Respecto a lo que comentabas al final sobre el error de imitar la interface de la implementación es algo que me he encontrado mucho y recibe el nombre de Header Interface http://martinfowler.com/bliki/HeaderInterface.html
    Para evitarlo, como comentas, es mejor pensar en los roles y responsabilidades de la interfaz desde el punto de vista del cliente, (como en RDD de Rebecca Wirfs-Brocks). Esta manera de hacer interfaces, Fowler la denomina Role Interface http://martinfowler.com/bliki/RoleInterface.html
    Creo que esta forma de diseñar las interfaces es mucho mejor porque no sólo te da un punto de indirección sino una abstracción útil para el cliente. Esta hará que la interfaz sea más estable y también más fácil de testear. Como dice Sandi Metz, cuando te centras en los roles y responsabilidades de la interfaz desde el punto de vista del cliente, “you can trade the unpredictability of what others do for the constancy of what you want.”
    Saludos,
    M

    1. Grande Manuel!!!

      La verdad es que siempre va bien conocer la nomenclatura estándar que comentas como lo del Header Interface y Role Interface. No sabía que existían estas denominaciones para este tipo de casos 😀

      Muchas gracias por el comentario!!

  2. Entonces por lo que tengo entendido, no tendría sentido hacer un VehicleInterface que definiera los getters/setters que ha de implementar cada vehículo no? Sino solamente tendría que definir esos métodos que han de ser útiles o visibles para por ejemplo en el caso de la BusStation saber algunos datos sobre el autobús no? Como cuanta gasolina le queda, cuando ha de pasar la itv, u otras cosas de interes de cara a quien lo utilice no?

    1. Buenas Sergio,

      Lo que dices es correcto, es precisamente el punto de este vídeo: Interfaces pensadas desde el punto de vista de los clientes que van a usar nuestras clases y no desde las implementaciones concretas de esas interfaces 🙂

Leave a Reply

Your email address will not be published.