Fragilidad=>se hace muy difícil mantener el software

Rigidez=> es muy difícil cambiarlo

Rediseñar aplicando principios de diseño

Principios de diseño
SOLID
Propuesta escrita por Robin C.Martin en los años 2000,la idea de esto es implementar una serie de principios
para hacer un código sostenible, mantenible y escalable en el tiempo, lo que ganamos aplicando dichos
principios SOLID es
- Ata Cohesión=> la colaboración entre clases
- Bajo Acoplamiento => que una clase dependa fuertemente de otra.

SRP => Principio de responsabilidad simple

Una clase tiene una y solo una razón para cambiarse, este principio ayuda a evitar esa fragilidad ,estos
principios son los que me van ayudar a minimizar los síntomas de(fragilidad, rigidez ) .que es lo que busca
significar , que tengo responsabilidades(puede ser una clase o puede ser un módulo) debería tener una sola
razón por la cual modificarse ,esto se hace para evitar otros problemas (fragilidad)

Lo que quiere decir esto es que una clase debe tener una razón para existir, más no para cambiar.
muchas veces cuando programamos, por ejemplo una clase que gestiona la información del usuario le
solemos dar responsabilidades que no están dentro del dominio del usuario. Entonces estamos rompiendo
este principio
Mejor propuesta es promover la cohesión, la colaboración entre clases, podemos crear una clase notificación,
así esta clase estaría disponible para otra clase, seria también más fácil de mantener
OCP =>Principio de abierto o cerrado
Para que se quiere lograr esto ¿? Para no cambiar lo que funciona si no extender ,por que se necesita
modificar el condigo, se tiene dos opciones .
1- O falla y hay que modificarlo(corregirlo)
2- O le extiendes funcionabilidad
Dice que si tengo que agregar comportamiento no tengo que tocar nada, eso es lo que busca este principio,
que sea abierto para la extensión y cerrado para la modificación es la Abstracción.

ESTE PRINCIPIO DE DISEÑO ES UNO QUE TIENE QUE PONDERAR SOBRE EL RESTO (este principio es
insacrificable) .
No siempre voy a poder cumplir con todos los principios

LSP =>El principio de sustitución de liskov

Las relaciones que utilicen puntero que referencian a la clase base deberían ser capases de
usarcé con las clases derivadas
PRINCIPIO DE SUSTATITIVILIDAD
ISP =>La segregación de la interfaz
Esto lo que me dice es que si tenemos interfaces, pesadas, gordas y tenemos clientes que depende de esa
interfaces(se introduce fragilidad ) .frase que me define esto=> “Hay interfaces específicas para un tipo de
cliente ”,que los clientes dependan de una interface especifica.
La frase que me describe este principio es que hay interfaces para un tipo de cliente (específicas para cada
cliente) se puede introducir fragilidad
Firma se le lo llama al nombre del método mas el parámetro
Que pasa con las clases abstractas y las interfaces ,quien esta obligada a implementar esos métodos es la
primer subclase concreta en la jerarquía
Puede implementar una interface una clase Abstracta ¿?
- Si puede, pero la clase abstracta no está obligada a implementar estos métodos, lo que sí está
obligada es la primera subclase concreta en la jerarquía
ESTE PRINCIPIO NOS SEPARA INTERFACES DE COSAS QUE NO NECESITO.
API=> interfaz para programar aplicaciones (ejemplos web service) api es la firma de todos los web service ,la
api es lo público ,el cual contiene métodos
Evita el Alto Acoplamiento.
DIP=>La inversión de dependencia
A. Las clases de alto nivel no deberían depender de las clases de bajo nivel.
Ambas deberían depender de las abstracciones.
B. Las abstracciones no deberían depender de los detalles. Los detalles
deberían depender de las abstracciones.

Estos principios se implementan en los patrones de diseño

- elisitacion de requerimiento
- especificamos ese requerimiento
- después a la etapa de diseño(iteración continua)

como identificar porque un diseño esta mal ,por eso los patrones de diseño ayudan a que esto no suceda

cuando veamos Patrones de diseño orientado a objetos vamos a introducir 2 principios mas

PROGRAMAR INTERFAZ NO IMPLEMENTACIONES

FAVORECER LA COMPOCICION SOBLE LA HERENCIA

NOSOTROS ESTAMOS VIENDO EL PARADIGMA ORIENTADO A OBJETOS

POO DOO
Cuáles son las bases de la programación orientada a objetos
- Abstracción
- Encapsulamiento
- Herencia
- Polimorfismo

Que me dice el diseño orientado a objetos

FAVORECER LA COMPOCICION SOBLE LA HERENCIA (se hace un uso intensivo de esto)

https://es.linkedin.com/pulse/favorecer-la-composici%C3%B3n-sobre-herencia-cristofer-padilla
Agregación y Composición: “Compuesto por”

Son asociación “todo parte”. Significa que comparten el ciclo de vida.

. Agregación: El lado “parte” puede convivir con varios “todos”.

. Composición: El lado “parte” se comunica con un solo “todo”.

Herencia: “Es un”

Relación de generalización. Es el primer mecanismo de reúso.
La relación de herencia lo que hace básicamente es reutilizar las especificaciones detalladas en la superclase
en una subclase.

La refactorización (del inglés refactoring) es una técnica de la ingeniería de software para

reestructurar un código fuente, alterando su estructura interna sin cambiar su comportamiento
externo.