Prevención de Efectos Dominó en Mantenibilidad de Software

Apuntes:

Prevenir efectos dominó. Trabaja estrictamente con las dependencias. Es decir, cuándo podemos detectar que un cambio generaría problemas en otros módulos u otras dependencias.
• Ocultar información. Cualquier módulo u objeto que diseñemos, tenga la capacidad de ocultar cierta parte de la información para que los agentes externos no dependan de esa información puntual sino de una interfaz clara que no puedan cambiar por más que la información cambie. De esta forma podemos garantizar que, si el cambio de la información es importante, los dependientes no necesiten cambiar porque están pasando por una interfaz que no cambió.
• Mantener la interfaz. Si tengo un servicio que hace algo, la dependencia a ese servicio va a ser a través de una interfaz clara, de lo contrario cualquier acción cuándo cambie puede poner en riesgo el módulo.
• Restringir comunicación. Para generar sistemas que estén acoplados de forma ligeras, en vez de conocer las dependencias de tus dependencias, siempre te limites a tus dependencias directas, de esta forma cualquier cambio en la forma que tus dependencias trabajan no afecta al módulo en el que estás trabajando.
• Intermediarios. Hablamos de un punto dónde podamos compatibilizar a un módulo con otro y si dejan de ser compatibles, estos intermediarios puedan servir como punto de compatibilidad.

Diferir enlace. Habla sobre cómo podemos hacer para que un cambio en nuestro código no requiera desplegar toda la aplicación completa.
• Registro en ejecución. Cuando un módulo o servicio depende de otro, si dependen fuertemente van a requerir estar compilados juntos. Si nosotros podemos diferir esa compilación y que se registre un servicio en momento de ejecución, es decir que se ponga disponible a sus dependencias en el momento de ejecución, podemos hacer que estos servicios se puedan desplegar independientemente.
• Archivos de configuración. Van a servir para en momento de ejecución saber cómo conectar varias partes. Es imprescindible que nuestros módulos dependan de interfaces y no de implementaciones específicas.
• Polimorfismos. Un objeto pueda comportarse de forma diferente en base a su estado. A través del polimorfismo podemos postergar la forma en que se resuelve un problema dependiendo de qué instancia del objeto será.
• Reemplazo de componentes. Tener la capacidad de desplegar un componente y luego desplegar su reemplazo, o quizás otro componente que respete esa interfaz, y que todo el resto de nuestra aplicación no necesite cambiar.
• Adherir a protocolos. Nos permite tener un protocolo claro entre dos módulos y no necesitar saber la instancia específica o el tipo específico de un módulo.

Ley de Demeter o el principio de menor conocimiento, esta ley dice que para generar sistemas que estén acoplados de forma ligera en vez de conocer las dependencias de tus dependencias siempre te limites a hablar con tus dependencias directas. De esta forma cualquier cambio en la forma en la que tus dependencias trabajan no afecta al modulo que estas trabajando.

Escenario: Mantenibilidad

Estimulo: Pedido de cambio / Nuevo requerimiento

• Prevenir efectos domino
  • Ocultar información
  • Mantener la interfaz
  • Restringir comunicación
  • Intermediarios
• Diferir enlace
  • Registro en ejecución
  • Archivos de configuración
  • Polimorfismo
  • Remplazo de componentes
  • Adherir a protocolos

Cambios semánticos. Si la semántica de lo que hacemos cambia, el modulo que lo implementa también cambiara. Se relaciona con el sentido. Cambia la lógica.
Cambios sintéticos. Cambios en la secuencia de lo que se hace. Los cambios de “Mantener la interfaz” funcionan aquí. Se relaciona con la estructura.

semantico: que se relaciona con el sentido
sintactico: que se relaciona con la estructura

COMPLETO:
Familias de tácticas:
1.- Confinar modificaciones. Las tácticas van a intentar trabajar sobre nuestros módulos para que cada cambio que nos pidan esté confinado a sólo un módulo. Cuando logramos esto logramos que las dependencias entre módulos sean más ligeras y el cambio que nos proponen no afecte a muchas partes del sistema.
a) Coherencia semántica. Habla de la relación entre las responsabilidades de los módulos. Hablamos de acoplamiento y cohesión. Si logramos encontrar la cohesión en un módulo entonces vamos a poder hacer que ese módulo sea más mantenible. De lo contrario es posible que ese módulo cambie por diferentes razones.
Abstraer servicios comunes. Cuando encontramos que la aplicación tiene servicios más genéricos de no necesario podemos abstraerlos a un punto común y que las dependencias vayan de los módulos cohesivos a un servicio o modulo externo.
b) Generalizar. Al generalizar un módulo podemos separar lo específico de lo genérico.
c) Limitar opciones disponibles. Limitar el rango de modificación nos ayuda a que sea más mantenible.
d) Anticipar cambios. Prepararnos para algún cambio que nosotros mismo sepamos que se deberá de dar en el futuro tomando en cuenta una estrategia sobre como incorporar el nuevo cambio. Los patrones de diseño suelen estar orientados a esto (Patrón estrategia).
2.- Prevenir efectos domino. Trabaja estrictamente con las dependencias, es decir cuando podemos detectar que un cambio generaría problemas en otros módulos o dependencias.
Prevenir efectos dominó. Trabaja estrictamente con las dependencias. Es decir, cuándo podemos detectar que un cambio generaría problemas en otros módulos u otras dependencias.
• Ocultar información. Cualquier módulo u objeto que diseñemos, tenga la capacidad de ocultar cierta parte de la información para que los agentes externos no dependan de esa información puntual sino de una interfaz clara que no puedan cambiar por más que la información cambie. De esta forma podemos garantizar que, si el cambio de la información es importante, los dependientes no necesiten cambiar porque están pasando por una interfaz que no cambió.
• Mantener la interfaz. Si tengo un servicio que hace algo, la dependencia a ese servicio va a ser a través de una interfaz clara, de lo contrario cualquier acción cuándo cambie puede poner en riesgo el módulo.
• Restringir comunicación. Para generar sistemas que estén acoplados de forma ligeras, en vez de conocer las dependencias de tus dependencias, siempre te limites a tus dependencias directas, de esta forma cualquier cambio en la forma que tus dependencias trabajan no afecta al módulo en el que estás trabajando.
• Intermediarios. Hablamos de un punto dónde podamos compatibilizar a un módulo con otro y si dejan de ser compatibles, estos intermediarios puedan servir como punto de compatibilidad.
3.- Diferir enlace. Habla sobre cómo podemos hacer para que un cambio en nuestro código no requiera desplegar toda la aplicación completa.
• Registro en ejecución. Cuando un módulo o servicio depende de otro, si dependen fuertemente van a requerir estar compilados juntos. Si nosotros podemos diferir esa compilación y que se registre un servicio en momento de ejecución, es decir que se ponga disponible a sus dependencias en el momento de ejecución, podemos hacer que estos servicios se puedan desplegar independientemente.
• Archivos de configuración. Van a servir para en momento de ejecución saber cómo conectar varias partes. Es imprescindible que nuestros módulos dependan de interfaces y no de implementaciones específicas.
• Polimorfismos. Un objeto pueda comportarse de forma diferente en base a su estado. A través del polimorfismo podemos postergar la forma en que se resuelve un problema dependiendo de qué instancia del objeto será.
• Reemplazo de componentes. Tener la capacidad de desplegar un componente y luego desplegar su reemplazo, o quizás otro componente que respete esa interfaz, y que todo el resto de nuestra aplicación no necesite cambiar.
• Adherir a protocolos. Nos permite tener un protocolo claro entre dos módulos y no necesitar saber la instancia específica o el tipo específico de un módulo.

Estos temas son un resumen de lo expuesto en este modulo…

 -------------------------------------------------
*)PRINCIPIOS GRASP
  +Encapsulamiento
  +Acoplamiento
  +Cohesion
  +Ley Demeter
  +Separation of Concerns
  +Invertion of Control
  +Don't Repeate Yourself
  +Keep it Simple Stupid
 -------------------------------------------------
*)PRINCIPIOS SOLID
  +Single Responsability Principal
  +Open/Closed Principal
  +Liskov Sustitution Principal
  +Interface Segregation Principal
  +Dependention Invertion Principal
 -------------------------------------------------
*)PATRONES ARQUITECTONICOS
  +Circuit Breaker
  +Publisher/Suscriber
  +Dashboard
  +Plugins
 -------------------------------------------------
*)PATRONES DISEÑO SOFTWARE
  ->CREACIONALES<-
  +Singleton
  +Prototype
  +Builder
  +Factory Method
  +Abstract Factory
  +Object Pool
  ->ESTRUCTURALES<-
  +Adapter
  +Bridge
  +Composite
  +Decorator
  +Facade
  +Flyweight
  +Proxy
->COMPORTAMIENTO<-
  +Iterator
  +Command
  +Observer
  +Tempalte Method
  +Strategy
  +Chain of Responsability
  +Interpreter
  +Mediator
  +Moment
  +Null Object
  +State
  +Visitor
 -------------------------------------------------

Los cambios provocan otros cambios no previstos en el sistema.
Tácticas:

• Ocultar Información
• Mantener la Interfaz
• Restringir Comunicación
• Intermediarios

• Registro en ejecución
• Archivos de Configuración
• Polimorfismo
• Reemplazo de Componentes
• Adherir a Protocolos

Cuando hablamos de ocular información hablamos de encapsulamiento? Por ejemplo

⭐️ Excelente ⭐️

⭐️⭐️⭐️⭐️⭐️