Diseño de Sistemas

Agenda

de la clase

• Modelando Eventos
• Consultas
• QMP VI: Puesta en Común
• Actividades para la próxima clase

2

1.

Modelando Eventos

Me pasan cosas...

3

Acciones ante

una acción

​

A

• A tiene responsabilidades propias
• Al realizar A una acción propia
• Deben dispararse otras acciones en el sistema
• Estas acciones son responsabilidad de otros componentes (B,C,D…)
• Son varias acciones diferentes
• Son acciones variables (en el tiempo, por cada instancia de A, etc.)

​

​

​

B

C

D

E

F

G

El enfoque

interactivo

​

A

• A le ordena a cada componente qué hacer
• A debe conocer específicamente todas las acciones a disparar (hardcodeo)
• A debe conocer específicamente a todos los componentes
• A debe saber qué tarea ordenarle a cada componente
• Al variar las acciones disparadas, A debe modificarse

​

​

​

​

B

C

D

E

F

G

Enviar mensaje de voz

Informar malas palabras

Detectar usuario molesto

Postear mensaje

El enfoque

interactivo

​

El enfoque

por eventos

​

A

• A les avisa a los demás que ocurrió un evento
• A no conoce cuales son las acciones a disparar
• A conoce genéricamente a todos los componentes (lista polimórfica)
• A les envía el mismo mensaje a todos los componentes
• Al variar las acciones disparadas, A ni se entera

​

​

​

​

B

C

D

E

F

G

*

* A este enfoque también se lo conoce como reactivo

Postear mensaje

Mensaje posteado!

Ok, voy a enviar un mensaje

de voz

Genial, ahora informaré malas palabras

Dale, ahora detecto si el usuario es molesto

El enfoque

por eventos

​

*

* A este enfoque también se lo conoce como reactivo

Eventos

y notificaciones

​

9

B

A

Suscripción

• B se suscribe a las novedades de A
• A genera eventos para todos sus suscriptores
• B se entera de las cosas que le pasan a A y hace algo al respecto

Generación de eventos

Enterarse

Claves del modelado

por Eventos

​

10

• Acuerdo de mensaje unificado para todos (por evento)

​

• Trato polimórfico de interesados

​

• Protocolo común para suscripción y de-suscripción

​

• Responsabilidades de qué hacer en los interesados

​

• Observado no altera su código al cambiar los interesados

​

• Fire & Forget (permite asincronismo)

​

​

​

​

Consultas

A repasar lo que no quedó claro

11

No me quedo del todo claro cómo notificar a los interesados sobre el evento. El orden en el cual se encuentran los observadores en la lista es importante verdad? Puedo controlar el flujo de cómo están ordenados los observadores y en caso de agregar uno nuevo asegurar que sea consistente el orden ?

12

“

No entendi a que se refiere con vetar eventos. Qué sería el VetoableChangeListener en el apunte de efectos del observer

13

“

14

15

Los objetos "interesados" serían los objetos que poseen la responsabilidad de validar/llevar a cabo un requerimiento del dominio? Qué sería un 'extension method'?

​

16

“

Sería como mezclar un observador con un Command (ya que entienden polimórficamente un mensaje notify generico). En ese caso lo que he visto es diferir la modificación (puede pasarse un estado mutable al observador, y luego de notificados todos, se procede a incorporar los cambios). De esta forma se desacoplan temporalmente y se evita tener que notificar incorrectamente.

17

“

18

Más

preguntas?

3.

Qué Me Pongo: Sexta Iteración

Puesta en común

19

4.

Para la próxima clase

A seguir aprendiendo

20

Para la clase que viene

Les estaremos enviando un email con:

• Apuntes para que lean sobre Patrones de Comunicación
• Form de seguimiento de los mismos
• Un video sobre Metodologías, para que lo miren
• La clase que viene, abordaremos el punto bonus de QMP VI

​

Recuerden enviar consultas al foro

​

21

Muchas Gracias!!

Si tienen consultas

https://github.com/dds-jv/foro

22