oop - responsabilidad - solid explicacion
En SOLID, ¿cuál es la distinción entre SRP y ISP?(Principio de responsabilidad única y principio de segregación de interfaz) (3)
SRP e ISP finalmente se reduce a las mismas cosas. La implementación, cualquiera de ellos, necesita una división de clases o interfaces.
Sin embargo, hay diferencias en otros frentes.
- La violación de SRP puede tener un efecto de gran alcance en toda la estructura de diseño, dando lugar a una mala mantenibilidad, reutilización y, por supuesto, baja cohesión y acoplamiento.
- SRP tiene un impacto en los componentes conductuales y estructurales de una estructura de objeto.
- Re diseñar en violación de SRP necesita un análisis mucho más profundo, requiere mirar los diferentes componentes del diseño de una manera holística.
La violación del ISP se debe principalmente a la mala legibilidad (y hasta cierto punto, a la baja cohesión). Pero el impacto en el mantenimiento y la reutilización del código es mucho menos siniestro que SRP.
Además, el código de refactorización a la conformación del ISP parece ser solo un cambio estructural.
¿Cómo se diferencia el "Principio de segregación de interfaz" de SOLID "Principio de responsabilidad única"?
La entrada de Wikipedia para SOLID dice que
ISP divide las interfaces que son muy grandes en otras más pequeñas y más específicas para que los clientes solo tengan que conocer los métodos que les interesan.
Sin embargo, para mí eso suena como simplemente aplicar el SRP a interfaces y clases. Después de todo, si una interfaz solo es responsable de una sola cosa conceptual, entonces no sería posible desglosarla aún más.
¿Me estoy perdiendo algo o el ISP es redundante con SRP? De lo contrario, ¿qué implica el ISP que SRP no lo haga?
SRP está preocupado con lo que hace un módulo, y cómo se hace, rechazando cualquier mezcla de niveles de abstracción. Básicamente, siempre que un componente se pueda definir extensamente con una sola oración, no romperá a SRP.
Por otro lado, ISP está preocupado por cómo se debe consumir un módulo, si tiene sentido consumir solo una parte del módulo, mientras se ignora algún aspecto.
Como ejemplo de un código que mantiene el espíritu o SRP, pero puede romper el ISP es el patrón de Fachada. Tiene una responsabilidad única, "proporcionar acceso simplificado a un subsistema más grande", pero si el subsistema subyacente necesita exponer puntos de vista completamente diferentes, rompe el ISP.
Dicho eso, generalmente cuando un código rompe un principio SÓLIDO, a menudo rompe todo. Los ejemplos concretos que rompen un principio específico, mientras que preservan el resto son raros en la naturaleza.
SRP nos dice que solo debe tener una responsabilidad única en un módulo.
El ISP nos dice que no debe verse obligado a enfrentarse con más de lo que realmente necesita. Si desea utilizar un método print() desde la interfaz I , no debería tener que instanciar una SwimmingPool o una clase DriveThru para eso.
Más concretamente, y yendo al grano, son puntos de vista diferentes sobre la misma idea: SRP está más enfocado en el punto de vista del diseñador, mientras que el ISP está más enfocado en el punto de vista del lado del cliente. . Entonces, básicamente tienes razón.
Todo vino de
El ISP fue utilizado y formulado por primera vez por Robert C. Martin cuando realizaba algunas consultas para Xerox. Xerox creó un nuevo sistema de impresora que podría realizar una variedad de tareas, como grapar un conjunto de documentos impresos y enviar y recibir faxes. El software para este sistema se creó desde cero y realizó sus tareas con éxito. A medida que el software creció, la modificación se hizo cada vez más difícil, por lo que incluso el cambio más pequeño llevaría un ciclo de reasignación a una hora. Esto estaba haciendo casi imposible continuar el desarrollo. El problema de diseño fue que una clase principal de trabajo fue utilizada por casi todas las tareas. Cada vez que se tenía que hacer un trabajo de impresión o un trabajo de grapado, se realizó una llamada a algún método en la clase Trabajo. Esto dio como resultado una clase enorme o "gorda" con multitud de métodos específicos para una variedad de clientes diferentes. Debido a este diseño, un trabajo básico sabría sobre todos los métodos del trabajo de impresión, aunque no había ningún uso para ellos.
asi que
La solución sugerida por Martin es lo que hoy se llama Principio de segregación de interfaz. Aplicado al software de Xerox, se agregó una capa de interfaces entre la clase de Trabajo y todos sus clientes utilizando el Principio de Inversión de Dependencia. En lugar de tener una clase grande de Trabajo, se creó una interfaz de Trabajo de Grapado o una de Trabajo de Impresión que sería utilizada por las clases de Grapado o Impresión, respectivamente, llamando a métodos de la clase Trabajo. Por lo tanto, se creó una interfaz para cada trabajo, que fue implementada por la clase Trabajo.
@ http://en.wikipedia.org/wiki/Interface_segregation_principle#Origin