Dudas con el parcial Findr

[ParedesMicaela]

Buenas tardes! Hice el parcial de findr y salí con más dudas que certezas. Esta es mi resolución, no hice el código porque seguramente tenga que cambiar muchas cosas pero explico más o menos lo que hice y mis dudas:

1. La grilla puede ser un singleton? Yo había pensado que en algún lugar voy a tener que guardar todos los perfiles de todos los usuarios y había hecho un RepoPerfiles pero como solamente guardaba perfiles y en los requerimientos me pedían cosas relacionadas a los perfiles que le interesan a 1 usuario, lo cambié por un singleton Grilla que conoce a todos los perfiles y aparte de eso se le puede aplicar filtros para que el usuario vea solamente los perfiles que quiere. Pero como voy a estar aplicandole filtros y cambios a un singleton no se me va a complicar a la hora de testear?

2. En el enunciado dice que si el perfil tiene como género no binarie, el usuario puede poner una descripción especificando qué genero es. Los géneros yo los puse como un enum sin comportamiento. Esto de la descripción lo puedo meter en el perfil general y después validar que si pone como género "no binarie" que le pide también una descripción?

3. En el enunciado dice que la foto se analiza automáticamente usando un sistema externo y si la IA marca la foto como dudosa, recién ahí se manda a que un moderador la revise manualmente. Yo puse que el análisis automático lo hace la foto usando una especie de adapter para desacoplar el análisis con la IA. El análisis manual se hace cuando la foto queda en el estado DUDOSO y uso un singleton donde voy a tener todas las solicitudes pendientes de revisión de fotos. Intenté hacer una especie de command porque como el análisis manual lo hace un moderador, es asincrónico y por lo que entendí se van encolando. Mi duda es si la idea es correcta y si la forma en que lo hice en el gráfico está bien.

4. Me piden notificar al usuario cuando una foto se rechaza o se acepta, esto lo hace la foto?

5. En el enunciado dicen que un usuario puede crear alertas para que cada vez que un perfil nuevo entre, le avise si ese perfil coincide con el tipo que le gusta al usuario. Me da la sensación de que voy a tener que usar un observer pero no sé bien quién observa ni quién es el observado. Yo supuse que la grilla es la que va a sumar a los conectados un perfil (que un usuario se conecte es algo que pasa) y que esa va a avisarle a todas las alertas que tiene que se conectó alguien y las alertas van a ver si ese alquien coincide con el tipo que le gusta al usuario y lo van a notificar. En mi diagrama intenté poner que la grilla es el observado y las alertas son los observadores porque entiendo que la grilla va a saber cuando se conecta alguien y va a tener las alertas de todos los perfiles. Eso es correcto? Las alertas se suscribirían cuando son creadas?

6. Las flechas de usa son ---> con la flecha rellena?

Disculpen tantas preguntas y gracias por su tiempo.

[flbulgarelli]

1. La grilla puede ser un singleton?

👀 Ojo: la grilla es el resultado de una operación que cada usuarie realiza contra el sistema, con lo que, conceptualmente, no habría una sino múltiples instancias de la grilla. En otras palabras, al mismo tiempo muchas personas pueden estar buscando perfiles.

Ahora bien, no necesariamente deberemos cosificar a la grilla, y en cambio podría ser tan solo la lista resultante de una operación de búsqueda de algun otro objeto del sistema: ¿cuenta con múltiples operaciones? ¿Es polimorfica con algún otro componente? ¿Tiene una identidad significativa? Estás son algunas preguntas que te pueden ayudar a razonar sobre ello.

[flbulgarelli]

Dicho eso, y viendo mejor los método que le diste a tu grilla y ésto que comentás...

Yo había pensado que en algún lugar voy a tener que guardar todos los perfiles de todos los usuarios y había hecho un RepoPerfiles pero como solamente guardaba perfiles y en los requerimientos me pedían cosas relacionadas a los perfiles que le interesan a 1 usuario, lo cambié por un singleton Grilla que conoce a todos los perfiles y aparte de eso se le puede aplicar filtros para que el usuario vea solamente los perfiles que quiere.

...entiendo que tu Grilla, al menos en su intención, es esencialmente un repositorio de perfiles, y que no tiene ninguna información asociada a un perfil en particular (sino que es un parámetro). Entonces la cuestión de Grilla vs RepoPerfiles es más una elección de nombres que un problema de diseño en sí (personalmente, la segunda opción me parece más evidente, pero no es algo tan taxativo).

Sobre ésto:

Pero como voy a estar aplicandole filtros y cambios a un singleton no se me va a complicar a la hora de testear?

Entiendo que tu Grilla sólo tiene estado global, descriptivo del estado general del sistema (los perfiles conectados) y no estado conversacional o específico, con lo cual no tendrías ni más ni menos problemas que con cualquier otro repositorio singleton, por lo que (si tu Grilla es sólo eso) no tendrás que tener otro cuidado que el de configurar y limpiar apropiadamente este componente global en tus tests.

Ahora bien, acá está el nudo gordiano de tu diseño: si bien parametrizaste al perfil que está buscando en los métodos de Grilla (👍), no hiciste lo mismo con los filtros y alertas que sí son parte del estado de perfiles particulares y no del sistema globalmente (👎). En otras palabras, es un error que tu Grilla sea singleton y a la vez refiera a una lista de alertas y otra de filtros, dado que cada persona debería poder configurar los suyos propios. Si no, estarás forzando a todas las personas a aplicar los mismos filtros, o, puesto de otra forma, le estará faltando al filtro la información contextual de quien lo especifica.

Acá yo veo sólo dos alternativas:

• O bien terminás de convertir a tu Grilla en un repositorio, global, donde el perfil buscador, los filtros y alertas sean siempre parametrizados;
• o bien, mantenés la idea de Grilla como un objeto para el que pueden existir una cantidad arbitraria de instancias, una para cada búsqueda que alguien haga, y que contenga el estado conversacional del perfil buscador, los filtros que aplicó y/o alertas.

Nota: es posible también que a la larga las dos ideas terminen conviviendo y termines teniendo tanto un RepositorioPerfiles singleton que manipule objetos Grilla, o al revés.

[ParedesMicaela]

AA claro, ahí yo tendría alertas y filtros iguales para todos y no configurables. Voy a hacer el repositorio de perfiles singleton y que este use muchos objetos grilla, que tiene más sentido.

[flbulgarelli]

En el enunciado dice que si el perfil tiene como género no binarie, el usuario puede poner una descripción especificando qué genero es. Los géneros yo los puse como un enum sin comportamiento. Esto de la descripción lo puedo meter en el perfil general y después validar que si pone como género "no binarie" que le pide también una descripción?

Sí, podría ser una alternativa. Otra alternativa es que el Genero sea un objeto no enumerado, con un atributo descripción y otro que represente el tipo o categoría. ¿Qué ventajas y desventajas le ves?

[ParedesMicaela]

Claro si hago una clase Genero que tenga un TipoGenero(hombre, mujer, ...) y una descripción, gano extensibilidad para en un futuro agregar más géneros y puedo permitirle a cualquier persona especificar algo en la descripción. Es verdad, para lo que busca la aplicación, la forma en que lo hice es limitante, no apliqué nada de la rendición de cuentas.

[flbulgarelli]

Yo puse que el análisis automático lo hace la foto usando una especie de adapter para desacoplar el análisis con la IA.

Estoy de acuerdo con la idea de introducir un adaptador. Lo que no me termina de quedar claro viendo el diagrama es el vínculo entre ese adaptador y VerifyGPT. Por lo que veo no introdujiste ninguna interfaz que habilite el polimorfismo, con lo que ese adapter sólo serviría para manejar la complejidad de uso del sistema original (que a decir verdad, no parece demasiado complejo), pero no aportaría nada en materia de testeabilidad, ni flexibilidad, ni tampoco desacoplaría demasiado a ambas partes del sistema porque en algún punto estas asumiendo que hay una única implementación posible, lo cual muy probablemente termine colándose en la semántica de las abstracciones que generes a partir de allí.

Sugeriría que introduzcas una interfaz polimórfica en el medio, siguiendo una idea de adapter más "de libro".

El análisis manual se hace cuando la foto queda en el estado DUDOSO y uso un singleton donde voy a tener todas las solicitudes pendientes de revisión de fotos.

OK. Esto mercería que lo desarrolles con un poco de código.

Intenté hacer una especie de command porque como el análisis manual lo hace un moderador, es asincrónico y por lo que entendí se van encolando.

Respecto a que ése análisis es asincrónico, estoy completamente de acuerdo. Sin embargo, cuidado, porque ese proceso es también manual, justamente. Eso significa que no deberá existir ningún componente en el sistema que efectivamente realice el análisis, sino que el sistema se deberá limitar a almacenar esas solicitudes y exponer operaciones para alguien pueda efectivamente marcar a la foto como válida o inválida.

[ParedesMicaela]

Okok, uso el adapter de libro. Y para la validación manual está bien entonces la interfaz ModerarManualmente? Es solo para mostrar que eso eventualmente se va a hacer pero quién lo hace y cómo, no es parte del modelo de mi sistema.

[flbulgarelli]

¡Hola! Si bien esto ya lo charlamos la clase pasada, para que no quede colgada esta pregunta, la respuesta es no: no deberíamos contar con dicha interfaz, dado que eso es una responsabilidad humana. En todo caso, será la responsabilidad del sistema mantener la cola o lista de fotos para procesar manualmente, de modo que quien tome esa tarea, pueda saber qué tareas pendientes hay.