Cómo prevenir efectos dominó en 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.

Carlos Enrique Ramírez Flores

Hace 6 años

Excelentes notas!! las he guardado!

Elmer Padilla Espinoza

Hace 6 años

Se agradece su resumen Antonio.

Abril Darynka Tapia Sosa

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.

David Andrade Morales

Prevenir efectos domino: Trabaja específicamente con las dependencias. Un efecto dominó de una modificación es la necesidad de realizar cambios en los módulos que no se ven afectados directamente por él. Por ejemplo, si se modifica el módulo A para lograr una modificación particular, entonces el módulo B se cambia solo por el cambio al módulo A. B debe modificarse porque depende, en cierto sentido, de A. (Importante aplicación en Programación orientada a objetos)

-Ocultar información – Capacidad de ocultar información para no depender de esa información puntual y más bien de un interfaz visual que serpa dependiente de los cambios.
-Mantener la interfaz – Interfaz clara para entender una dependencia, un único llamado (Pasos en un cálculo de impuestos) sirve en cambios sintácticos.
-Restringir comunicación Evitar las cadenas de llamadas a objetos interminables, restringimos comunicación solamente a módulos que realmente necesitemos. (Ley de menor conocimiento)
-Intermediarios Punto de compatibilidad de un módulo con otro. (Patrón proxy, adapter, etc.)

Diferir enlace: Cómo hacer para que un cambio en código no requiere hacer un despliegue de toda nuestra aplicación. Aplazar el tiempo de enlace es compatible con los escenarios previamente mencionados a costa de requerir infraestructura adicional para admitir el enlace tardío (Importante aplicación en Programación orientada a objetos)

-Registro en ejecución – Permite desplegar servicios independientemente.
-Archivos de configuración – Sirven para saber cómo conectar varias partes (nuestros módulos deben depender de interfaces). (arquitectura plug-ins)
-Polimorfismo – Es el que un objeto pueda comportarse de manera diferente dependiendo de su estado. (el estado “state”)
-Remplazo de componentes – Capacidad de desplegar componentes sin necesidad de cambiar (el enlace y los componentes deben ser diferidos a la carga de la aplicación)
-Adherir a protocolos – Permite tener un protocolo claro entre dos módulos sin necesidad de conocer la instancia específica

Jerry David Malloney Romero

Excelente resumen, lo usare como material de estudio

juan celedon

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

Francisco Rafael Del Roio

Hola,

Pregunta tonta: ¿se evalúa lo aprendido de alguna manera a parte del exámen?

Saludos,

Bulmaro Arellano Navarrete

Hola,

Digamos que oficialmente Platzi únicamente reconoce los exámenes, hablo de Platzi como sistema o plataforma de aprendizaje. Siendo Platzi consciente de que un examen no es suficiente nos invita a desarrollar ejercicios o proyectos cortos propios y compartirlos con los demás miembros de la comunidad a través del foro y en los diferentes grupos de Telegram para así complementar y mejorar tus habilidades y conocimientos que van más allá de un examen.

Saludos

Francisco Rafael Del Roio

Hola, muchas gracias por la info.

Juan Carlos Ortiz Romero

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.

Francisco Serrato Jiménez

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
 -------------------------------------------------

Christian Gómez

Hace 6 años

Prevenir efectos Domino:

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

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

Diferir enlace:

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

Lautaro Cabral

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

Mauricio Costanzo

Creo que si se refiere a eso ....

Por ejemplo: Tenemos la clase Producto y una de las propiedades es precio. Cuando hagamos una instancia de esa clase y queramos acceder a la propiedad precio, quizas lo mejor es *acceder a tal propiedad mediante una función. ¿Por qué? debido a que si mañana se nos ocurre darle condiciones a al precio del producto (Por ejemplo: si nos dan un requisito nuevo que dice: si el usuario en mayorista el precio se debería reducir)

De esta manera no deberíamos tener que cambiar cambiar nada en nuestro código donde se esté usando tal funcion que devuelve precio porque la lógica la habriamos implementado en la misma. En el caso contrario donde se estuviera usando directamente la propiedad si deberíamos cambiar todo.

*usualmente se le llaman función de tipo getters

Arbey Aragon

¿Donde puedo saber mas de patrones de diseño?

Diego Forero

Team Platzi

La verdad hay mucha información en internet, puedes buscar por software design patterns y vas a tener mucha información, eso si toda en ingles.

Antonio Madrid

Te recomiendo curso de Patrones de diseño de Luis Fernández, es de lo mejorcito que he hecho.

William Schnaider Torres Bermon

Hace 2 años

Adherencia a Protocolos

Definición

Utilización de protocolos de comunicación estandarizados para el intercambio de información entre módulos, permitiendo que evolucionen independientemente mientras respeten el contrato establecido.

Protocolos Comunes

REST, GraphQL para APIs web
gRPC, Thrift para comunicación entre servicios
AMQP, Kafka para mensajería
JSON, XML, Protocol Buffers para serialización

Beneficios

Desacopla productores y consumidores de servicios
Facilita la evolución independiente de componentes
Mejora la interoperabilidad entre sistemas heterogéneos
Simplifica la integración con sistemas de terceros

Buenas Prácticas

Versionado explícito de APIs
Documentación detallada (OpenAPI, Swagger)
Compatibilidad hacia atrás cuando sea posible
Diseño de contratos centrado en el dominio, no en la implementación

William Schnaider Torres Bermon

Hace 2 años

Prevenir Efectos Dominó

Objetivo: Evitar que un cambio en un módulo cause una cascada de cambios en otros módulos del sistema.

a) Ocultar Información

Definición mejorada: Implementar encapsulación para que los módulos externos dependan solo de interfaces estables y no de detalles de implementación.
Beneficios:
- Reduce dependencias entre módulos
- Permite cambios internos sin afectar a los consumidores
- Simplifica el mantenimiento a largo plazo
Ejemplo práctico: Un módulo de cálculo de impuestos que expone métodos públicos estables mientras los algoritmos internos pueden cambiar según nuevas regulaciones.
Principio relacionado: Encapsulación en programación orientada a objetos.

b) Mantener Interfaces Estables

Definición mejorada: Definir claramente cómo otros componentes interactúan con un módulo mediante un conjunto consistente de funciones.
Técnicas:
- Contratos de interfaz bien definidos
- Versiones de API para cambios significativos
- Uso del patrón Fachada para unificar puntos de acceso
Beneficio clave: Permite actualizar implementaciones internas sin afectar a los clientes del servicio.
Ejemplo: Añadir pasos adicionales a un proceso interno mientras se mantiene la misma firma de método en la interfaz pública.

c) Uso de Intermediarios

Definición mejorada: Implementar componentes que actúen como puentes entre módulos incompatibles o que puedan cambiar independientemente.
Patrones aplicables:
- Patrón Fachada (FACADE): Simplifica interfaces complejas
- Patrón Proxy: Controla acceso a objetos
- Patrón Adaptador (ADAPTER): Convierte interfaces incompatibles
Beneficios:
- Gestiona cambios en interfaces sin propagar efectos
- Facilita la evolución independiente de componentes
- Mejora la testabilidad de los módulos

d) Aplicar la Ley de Demeter (Complemento)

Definición: Principio de mínimo conocimiento - un objeto debe tener conocimiento limitado sobre otros objetos.
Regla práctica: Un método de un objeto debe invocar solo:
- Métodos del propio objeto
- Métodos de parámetros pasados al método
- Métodos de objetos creados dentro del método
- Métodos de componentes directos del objeto

Paul Osinga

⭐️ Excelente ⭐️

Juan Carlos Ortiz Romero

⭐️⭐️⭐️⭐️⭐️

Julian Camilo Vargas

Hay algún curso de conceptos básicos de programación? Estoy comenzando y es difícil entender algunos términos que usa guido. Seria muy bueno tener todos estos conceptos al menos visibles.

Sergio Atanacio

Puedes tomar el curso de programación basica de platzi.

Daniela García Lara