PRINCIPIOS SOLID

1. TRABAJO DE INVESTIGACION
PRINCIPIOS SOLID Y EXTENSION
Estudiante: José Carlos Mollinedo Mollisaca Turno: Noche
Materia: Taller de Sistemas I Fecha: 04/05/2022
----------------------------------------------------------------------------------------------------------
Principios Solid
Son una serie de normas o recomendaciones que guían la forma de desarrollar sistemas.
Con los principios SOLID se busca:
• Tener un código mantenible
• Fácil de aplicar cambios y arreglar errores.
• Facilitar la incorporación de nuevas funcionalidades
Para tener un código más legible y fácil de entender
1. Principio de Responsabilidad Única (Single Responsability)
Cada clase debe tener una sola responsabilidad, debe encargarse de una sola parte del sistema,
con el fin de que las clases realicen un solo trabajo para asegurarnos de que cada clase este
trabajando perfectamente.
Sin este principio:
Con este Principio:

2. 2. Principio Abierto – Cerrado (Open Closed)
Una entidad debe estar abierta para su extensión, pero cerrada para las modificaciones, con el fin
de que la funcionalidad básica del sistema se encuentre protegida.
Para añadir funcionalidades, escribir nuevo código, no modificar códigos existentes que ya
funcionan.
Se busca escribir código que no se tenga que cambiar cada vez que se tenga que modificar los
requerimientos.
Sin este Principio:

3. Con este Principio:
3. Principio de Sustitución de Liskov (Liskov Substitution)
Toda clase que es hija de otra clase, debe poder utilizarse como si fuera la clase padre.
Declara que una subclase debe ser sustituible por su superclase, y si al hacer esto, el programa
falla, estaremos violando este principio.
Sin el Principio:

4. Con el Principio:
4. (Interface Segregation)
Este principio establece que los clientes no deberían verse forzados a depender de interfaces que
no usan.
Dicho de otra manera, cuando un cliente depende de una clase que implementa una interfaz cuya
funcionalidad este cliente no usa, pero que otros clientes sí usan, este cliente estará siendo
afectado por los cambios que fuercen otros clientes en dicha interfaz.
Sin este Principio:

5. Con este Principio:
5. (Dependency Inversion)
Establece que las dependencias deben estar en las abstracciones, no en las concreciones. Es decir:
• Los módulos de alto nivel no deberían depender de módulos de bajo nivel. Ambos
deberían depender de abstracciones.
• Las abstracciones no deberían depender de detalles. Los detalles deberían depender de
abstracciones.
Sin este Principio:

6. Con este Principio:

7. Extensión en Desarrollo de Software
Un complemento designa un módulo de software opcionalmente disponible que amplía o cambia
las aplicaciones del programa principal con respecto a las funciones disponibles. En la literatura,
el término a veces se utiliza como sinónimo de extensiones, aunque existen claras diferencias
entre los dos.
Los complementos son en su mayoría desarrollados por el fabricante o instalados por el usuario.
La aplicación principal carga la extensión en la memoria principal cuando se inicia el programa
para que se pueda acceder a ella si es necesario. De esto se deduce que los complementos no se
pueden ejecutar sin una aplicación principal de marco.
Para que dichas extensiones se puedan programar para determinadas aplicaciones de software, se
crean interfaces independientes (API) como parte del desarrollo de la aplicación y la
implementación del software principal, que los complementos utilizan como puerta de enlace.
Ejemplo, el complemento del navegador: los complementos del navegador representan módulos
de software para la visualización de contenido especial que los navegadores no pueden mostrar
por sí mismos. Esto distingue estos complementos de las extensiones de software que cambian la
aplicación del navegador directamente.