Este principio aplica en aquellos casos donde hay un módulo con gran cantidad de funcionalidad donde se puede dividir, a través de la creación de nuevas interfaces más pequeñas, de manera que los distintos clientes sólo usen aquello que necesitan.
Por ejemplo, si tenemos varios usuarios y estos utilizan distintas operaciones de la clase «Ops» de manera que el «User1» utiliza sólo «op1», «User2» utiliza sólo «op2» y «User3» utiliza sólo «op3».
En este caso el código fuente de «User1» dependerá de los métodos «op2» y «op3» incluso si no los utiliza. Esta dependencia significa que un cambio en «op2» fuerce a «User1» a recompilar y redesplegar incluso sin llegar a utilizarlo.
Este problema se puede resolver si se segregan las operaciones por interfaz.
Si imaginamos que se utiliza un lenguaje estáticamente tipado, entonces el código de «User1» depende de una interfaz «U1Ops» y no de «Ops». De esta manera un cambio en «Ops» no afecta a «User1».
ISP y el lenguaje
Los lenguajes compilados dependen más de este tipo de principio ya que las dependencias de código pueden forzar a compilar y desplegar la aplicación.
En los lenguajes interpretados no existen estas dependencias de código que obliguen a un redespliegue.
Esta es una de las razones por las que los lenguajes dinámicos crean sistemas más flexibles y menos acoplados que los lenguajes compilados.
ISP y la arquitectura
En general no es una buena práctica depender de módulos que contienen más de los necesarios. Es más obvio cuando se fuerzan una nueva compilación y despliegue innecesarios.
En el nivel de arquitectura ocurre lo mismo. Si un sistema S depende un framework F y este a su vez depende de una base de datos DB, un fallo en DB podría causar que F y S dejen de funcionar.
No hay comentarios:
Publicar un comentario