sábado, 16 de abril de 2016

c.    L-iskov Substitution Principle
        I. ¿Qué significa la L-iskov Substitution Principle?
           Básicamente que cada clase que hereda de otra, puede usarse como su padre sin necesidad de conocer las diferencias entre ellas.
       
        II.  ¿Puede no cumplirse?
             Sí se cumple. De hecho, el Builder está creado para crear siempre objetos con las misma características. Es posible hacer una sustitución de una clase que herede de una clase A, por otra clase que también esté heredando de la clase A, sin causar problemas en las clases, pues siempre estarán formadas de las mismas caracteristicas.

 d.     I-nterface segregation
          I. ¿Qué significa la I-nterface segregation Principle?
             Establece que ningún cliente debe ser forzado a depender de métodos que no utiliza. Se deben dividir interfaces grandes en otras pequeñas basadas en grupos de métodos, sirviendo a submodulos.
 
          II.  ¿Puede no cumplirse?
                Sí se cumple. El builder esta creado para usar solo los métodos necesarios en cada grupo de concreteBuilder. Y dividido en partes pequeñas de productos.

e.      D-ependency inversion:

          I. ¿Qué significa D-ependency inversion?
             "Los módulos de alto nivel no deberían depender de módulos de bajo nivel, ambos deberían depender de abstracciones" y "Las abstracciones no deberían depender de detalles sino que los     detalles deberían depender de las abstracciones". Esto significa que en ningún lugar de nuestro     código deberíamos depender de una implementación actual, sino que en su lugar debemos     depender de interfaces o clases abstractas. ¿Y por qué deberíamos hacer esto? Porque esto nos     habilita a cambiar cualquier implementación por otra y ninguna otra clase que hayamos codificado debe saberlo o importarle. Si, es así, a ninguna otra clase debe importarle que el cambiemos un colaborador por otro.

            II. ¿Puede no cumplirse?
                 No se cumple, ya que el concrete builder depende directamente del builder, para evitar este inconveniente es necesario implementar una interfaz y que la clase builder la implemente de esta manera builder no sabrá lo que sucede en su clase principal y se pueden hacer cambios sin importarle.





No hay comentarios:

Publicar un comentario