M2 significado amigo

[manujurado1]

• Se ha creado la estructura del objeto valor Amigo con su constructor. Se ha mantenido la inmutabilidad ya que será la entidad del grupo de amigos la que creará los objetos valores amigos y estos serán únicos a dicho grupo de amigos.
• Hacer atributos accesibles.
• Se han añadido los métodos que permiten cambiar la disponibilidad de un jugador y los que permiten aumentas y disminuir el nivel del mismo. closes https://github.com/manujurado1/SportsBar-IV/issues/114

[manujurado1]

@JJ Esto también estaría listo para revisión. Para ir avanzando he dado por hecho que #113 está correcto. Si hubiera que cambiar algo del objeto valor nivel, tendría que adecuar estar parte también a posteriori. Muchas gracias!

[manujurado1]

Gracias por la correción @JJ Si, en este caso dudé bastante con el tema de la inmutabilidad ya que veía un poco raro lo de destruir y crear el objeto cada vez que se modificara la disponibilidad o el nivel, pero si es verdad que como PMV que resuelva el issue puede servir.

Por último, el tema de incluir los apellidos es algo que no considero necesario, yo considero que con el nombre/apodo (ya que en grupos de amigos hay personas con el mismo nombre pero siempre se les identifica de manera diferente) es suficiente.

Ya que encontrar un nombre en una lista que va a tener de normal entre 5 y 10 elementos no es tan costoso como para tener que ordenarlo alfabéticamente. En todo caso, podría ser una idea a considerar ordenarlo alfabéticamente en función del nombre/apodo introducido.

¿Qué opinas?

[JJ]

Gracias por la correción @JJ Si, en este caso dudé bastante con el tema de la inmutabilidad ya que veía un poco raro lo de destruir y crear el objeto cada vez que se modificara la disponibilidad o el nivel, pero si es verdad que como PMV que resuelva el issue puede servir.

Por último, el tema de incluir los apellidos es algo que no considero necesario, yo considero que con el nombre/apodo (ya que en grupos de amigos hay personas con el mismo nombre pero siempre se les identifica de manera diferente) es suficiente.

Tienes que entender que el considerar necesario algo o no no debe entrar en una metodología de ingeniería de un producto. Tienes que atender a las historias de usuario y a los propios problemas que tengas que resolver. En este caso, incluir apellidos respondería a la necesidad de presentar las listas en un orden alfabético (o en un orden cualquiera), pero también permite historias de usuario adicionales como que dos personas con el mismo apellido no estén en el equipo, o que estén.

De todas formas, lo del apellido es lo de menos. Lo más importante aquí es que no estás asegurando que el nombre sea único. El nombre y cualquier otra cosa que elijas para que sea único (un nick, un móvil) son lo que lo hacen inmutable.

Y ya que hablamos del móvil, o para el caso del mismo nombre, una de las rúbricas de #80 es "tiene en cuenta las consideraciones éticas" o algo por el estilo. Cuando incluyas en cualquier cosa nombres personales, tienes que tener en cuenta la GDPR. Principalmente es una consideración de interfaz de usuario, pero también tienes que tener la capacidad técnica de decir el nombre del fichero donde se depositan los datos personales y derecho a modificación y demás. Es el tipo de cosas que tampoco hacen en ningún TFG, pero que conviene que conozcas y uses (por ejemplo, creando una historia de usuario al respecto)

Ya que encontrar un nombre en una lista que va a tener de normal entre 5 y 10 elementos no es tan costoso como para tener que ordenarlo alfabéticamente. En todo caso, podría ser una idea a considerar ordenarlo alfabéticamente en función del nombre/apodo introducido.

También, ya que hablamos de la GDPR, puede usarse para generar IDs único en las listas, que no pueden incluir el nombre completo, si es que se va a poner, no sé, en el tablón de anuncios del sitio donde jugáis. Ya sé que no vais a hacer eso, pero una vez más, son posibles historias de usuario que tienes que respetar.

[manujurado1]

De todas formas, lo del apellido es lo de menos. Lo más importante aquí es que no estás asegurando que el nombre sea único. El nombre y cualquier otra cosa que elijas para que sea único (un nick, un móvil) son lo que lo hacen inmutable.

Pero es que el objeto valor amigo solo tiene sentido dentro de la entidad que lo gestiona, en este caso "Grupo de amigos". Por lo que es la misma entidad la que tiene que asegurarse cuando se incluya un nuevo amigo que no existe ya un amigo con ese mismo identificador (en este caso el nombre).

Y respecto a la GDPR, el nombre/identificador que se use no tiene que hacer referencia al nombre real ni nada que pueda afectar a la protección de datos. El nombre es simplemente la forma de reconocer a una persona dentro de un grupo. Llevándolo a la vida real, dentro de un grupo de amigos, cada miembro se le reconoce con un nombre distinto, ya puede ser su nombre normal, su nombre acortado (Javi para alguien que se llame Javier), un acortamiento de su apellido o algún mote que no tenga ninguna relación con su nombre real. Eso es lo que debe contener el atributo nombre, un identificativo que te haga único dentro de tu grupo de amigos, pero no tiene por qué ser único en el mundo (Puede haber millones de personas que le llamen Javi en el mundo, pero si el contexto es tu grupo de amigos, si que sabes a que persona se refiere únicamente al nombrar a Javi).

Espero haberme sabido explicar, porque me cuesta mucho a veces.

[JJ]

De todas formas, lo del apellido es lo de menos. Lo más importante aquí es que no estás asegurando que el nombre sea único. El nombre y cualquier otra cosa que elijas para que sea único (un nick, un móvil) son lo que lo hacen inmutable.

Pero es que el objeto valor amigo solo tiene sentido dentro de la entidad que lo gestiona, en este caso "Grupo de amigos". Por lo que es la misma entidad la que tiene que asegurarse cuando se incluya un nuevo amigo que no existe ya un amigo con ese mismo identificador (en este caso el nombre).

Eso es así para todos los objetos valor. Pero lo más importante aquí es que decisiones de diseño >>>>>>> decisiones en tiempo de ejecución, o sea que asegurarse en el diseño de un objeto valor que es único (para lo cual tienes que haberte previamente planteado el problema de que debe ser único) >>>>>> comprobar en tiempo de ejecución si es único o no y luego tomar alguna decisión ad hoc (de la que luego te arrepentirás).

Y para asegurarse de que es único, tienes que añadir al nombre y apellidos un dato que permita al amigo identificar que se trata de esa persona. No me valen "números de orden" o "ID único con UUID". Y todo esto tienes que ponerlo también en una historia de usuario correspondiente (que creo que no has hecho todavía), del estilo "Como amigo quiero saber en qué equipo estoy buscándome de forma fácil en los listados (o lo que sea)" (de camino esto también justificaría, para facilitar, que almacenaras en nombre y apellido). Una vez más, puedes decir que "no hace falta porque no van a ser muchos", pero esa no es la justificación adecuada. En programación, la justificación es siempre si añade valor al cliente o no. ¿Añade valor al cliente que puedan aparecer por orden alfabético habitual, por apellidos? Si la respuesta es que sí, entonces es una buena justificación para la decisión de diseño. ¿Añade deuda técnica o algún tipo de decremento en prestaciones o almacenamiento? No, porque más o menos va a ocupar lo mismo.

Y respecto a la GDPR, el nombre/identificador que se use no tiene que hacer referencia al nombre real ni nada que pueda afectar a la protección de datos. El nombre es simplemente la forma de reconocer a una persona dentro de un grupo. Llevándolo a la vida real, dentro de un grupo de amigos, cada miembro se le reconoce con un nombre distinto, ya puede ser su nombre normal, su nombre acortado (Javi para alguien que se llame Javier), un acortamiento de su apellido o algún mote que no tenga ninguna relación con su nombre real. Eso es lo que debe contener el atributo nombre, un identificativo que te haga único dentro de tu grupo de amigos, pero no tiene por qué ser único en el mundo (Puede haber millones de personas que le llamen Javi en el mundo, pero si el contexto es tu grupo de amigos, si que sabes a que persona se refiere únicamente al nombrar a Javi).

Si esa es la decisión de diseño que vas a tomar, refléjalo en el nombre que le vayas a dar a la variable. Aún así, deberías meter un campo adicional que te asegures que sea único, así no tienes que buscar para cada mote si ya existe o no.

Espero haberme sabido explicar, porque me cuesta mucho a veces.

La cuestión principal es que las explicaciones a posteriori no son demasiado adecuadas; tienes primero que especificar claramente qué problema estás resolviendo y todos los aspectos que tiene, y a continuación justificar las decisiones específicas en los mensajes de commit y en el propio código. En este commit b9f4ea9b910a61d4c1dcbdeb29f54adf2311fa25 no lo has hecho. Has dicho qeu se mantiene la inmutabilidad, lo que no es cierto, porque nivel y disponibilidad no lo son, y has dicho:

será la entidad del grupo de amigos la que creará los objetos valores amigos y estos serán unicos a dicho grupo de amigos

lo que tampoco es cierto, porque desde esa estructura de datos no se está llamando al constructor y a otras funciones.

Piensa que si lo primero que se te ocurre para un objeto determinado es una entidad y no un objeto valor, va a estar mal. Generalmente tendrás que diseñar una serie de objetos valor, y luego más adelante las entidades.

[manujurado1]

He rebaseado la rama para obtener los cambios que he hecho en #113 y en el último commit he arreglado la solución al issue en función de lo discutido, indicando en el mensaje de commit el motivo de las decisiones tomadas.

[manujurado1]

Vale, entiendo lo de quitar el nivel y la disponibilidad y eso manejarlo desde la entidad. Lo que no termino de entender, es el motivo por el que se necesita otra manera de identificar al amigo aparte del nombre. Que entiendo que tiene que ser un motivo de peso ya que me lo has comentado varias veces, pero no logro verle la utilidad.

Por otra parte, en la memoria, ¿Qué debería exactamente añadir? ¿Dentro del apartado "análisis del problema" cómo he definido cada uno de los objetos valor que voy declarando?

[JJ]

Vale, entiendo lo de quitar el nivel y la disponibilidad y eso manejarlo desde la entidad. Lo que no termino de entender, es el motivo por el que se necesita otra manera de identificar al amigo aparte del nombre. Que entiendo que tiene que ser un motivo de peso ya que me lo has comentado varias veces, pero no logro verle la utilidad.

Te voy a escribir una historia de usuario mejor.

Por otra parte, en la memoria, ¿Qué debería exactamente añadir? ¿Dentro del apartado "análisis del problema" cómo he definido cada uno de los objetos valor que voy declarando?

Los principales retos y como has aplicado la metodología. Recuerda que la metodología no está ahí para contarla, sino para usarla. Cuanto tiempo has tardado, qué cosas has aplicado, todo eso.

[manujurado1]

Con la HU he entendido mucho mejor lo que tengo que hacer, gracias!

[manujurado1]

Adapté el issue #114 a la nueva HU #119 y ya está añadido el día y mes de nacimiento y generado el id en función de este y el nombre. Una vez esté la parte de la estructura de datos correcta, actualizaré la memoria para no tener que ir actualizándola en cada corrección de los modelos que tenga que hacer hasta conseguir los correctos.

[JJ]

Por cierto, que usar un nombre y una cadena como fecha tampoco es adecuado, porque tienes que comprobar cada uno de ellos para que sean correctos, y más cuando usas convenciones como que el mes vaya en manúscula. Yo usaría una fecha almacenada en un tipo fecha, que sabes seguro que lo es. Recuerda que el código limpio dice también que los tipos son documentación, y deben usarse con su propia semántica, por lo que usar un int + una cadena para representar día del mes = int y mes = cadena no es correcto y genera deuda técnica.

[manujurado1]

Ya le he dado una vuelta a todo lo comentado! @JJ

[manujurado1]

Hombre, para ser precisos, deberías

1. Usar el mismo nombre que en la historia de usuario, que es Jose
2. Generar aleatoriamente las fechas dentro de un rango más o menos razonable, suponiendo que tus amigos tienen entre, no sé, 22 y 33 años.

Pero son temas de detalle que tampoco bloquean aceptarlo.

Vale, me pongo con ello y con la actualización de la memoria de lo avanzado respecto a los objetos valor

[manujurado1]

Cambiado el nombre del test y memoria actualizada. Lo del rango de fechas no he visto manera sencilla de hacerlo.

El siguiente paso, y el último para cerrar este milestone, entiendo que es definir la estructura de datos de la entidad, ¿estoy en lo correcto?