Please enable JavaScript.
Coggle requires JavaScript to display documents.
Principios SOLID (Dependency inversion (Inversion de dependencias)…
Principios SOLID
S
ingle responsability (responsabilidad unica)
Establece que cada módulo o clase debe tener responsabilidad sobre una sola parte de la funcionalidad proporcionada por el software y esta responsabilidad debe estar encapsulada en su totalidad por la clase.
Para identificar que no se está cumpliendo el principio existen pistas como:
2 capas de la arquitectura se mezclan en la misma clase
El número de los métodos públicos es grande
El número de imports no es común
Es difícil probar las clases
Cada vez que se escribe una nueva funcionalidad, la clase es afectada
El número de líneas de código no es normal
O
pen-closed (Abierto-cerrado)
Si se tiene un programa y se necesita una nueva funcionalidad, no se debe modificar funcionalidades, estructuras, etc. Anteriormente creadas en vez de eso debería extenderse sin modificarse.
Establece que una clase, módulo, función, etc. debe quedarse abierta para su extensión, pero cerrada para su modificación.
Para identificar que no se está cumpliendo el principio existen pistas como:
Si se necesita una nueva funcionalidad y se están tocando clases puede significar que no se está respetando el principio.
L
iskov Substitution (Substitución de Liskov)
Si en alguna parte de nuestro código estamos usando una clase, y esta es extendida, tenemos que poder utilizar cualquiera de las clases hijas y que todos los métodos de la clase sigan siendo válidos.
Si un método sobrescrito no hace nada o lanza una excepción, es posible que se esté violando el principio
Propicia el uso correcto de la herencia
I
nterface Segregation (Segregación de interfaces)
Los clientes de un programa dado solo deberían conocer de este aquellos métodos que realmente usan y no aquellos que no necesita usar
Ventajas
Propicia el desacoplamiento entre módulos
Prevenir errores inesperados y dependencias no deseadas
Reutilización de código
D
ependency inversion (Inversion de dependencias)
Es un patrón utilizado para desacoplar la relación entre objetos y sus dependencias
La responsabilidad de crear las dependencias es externa al componente que la requiere
Las dependencias podrían variar en su implementación mientras cumplan una interfaz o contrato establecido
Beneficios
• Simplifica la configuración de comportamiento
• Promueve la separación de responsabilidades
• Facilita pruebas en el código
Contenedor de dependencias
Posee dos funcionalidades
Registrar. El contenedor registra una clase concreta asociada a un tipo
Resolver. El contenedor genera un objeto concreto
Es un componente encargado de crear múltiples dependencias de objetos e inyectarlos cuando son requeridos en una aplicación.