JJ
commented
2 years ago No estoy diciendo que todos los objetos sean inmutables. Me parece genial que estés 4 horas pensando qué estructura tienes que usar, porque eso es la programación: mucho pensar, y cuando se acabe de pensar, ponerse a programar.
La ventaja que veo de usar objetos inmutables es que se puede reutilizar el mismo objeto varias veces en distintas estructuras ahorrando espacio y creaciones.
Por lo tanto veo correcto usar objetos inmutables para tipos y mutables para cosas que, efectivamente, mutan.
El proyecto consiste en ayudar a modificar proyectos de canciones de karaoke. En un proyecto tienes una lista de notas, cada nota forzosamente va a suceder en un momento diferente, por la que ya nunca se va a poder aprovechar la ventaja de los objetos inmutables de ser reutilizados.
Como el proyecto es para modificar canciones, el código actual ya requiere modificar todas y cada una de las notas al estimar su tono, volvería a requerir modificarlas al aplicar un algoritmo de posprocesado que tuviera en cuenta la clave de la canción para mejorar la precisión y volvería a requerir modificarlas para cualquier utilidad que ayudara a afinar su localización en el tiempo. Todo estas tareas se relacionan directamente con generar valor para el usuario satisfaciendo #7.
Le he estado dando vueltas casi 4 horas a encontrar motivos para hacer las notas inmutables, pero la realidad es que va a requerir más código, va a ser menos fácil de entender y mucho menos eficiente.
Según DDD no sé si podría ser considerado un objeto valor, creo que su posición como nota num. x dentro de una canción le da cierta identidad. Igualmente una decisión técnica tiene que estar justificada por un beneficio claro, no voy a tomarla solo para seguir de forma dogmática un enfoque.
Según el razonamiento anterior, el resto de clases:
PlayerChange debería ser inmutable, se puede reutilizar y no requiere ser mutado con frequencia.
MetaData no se reutiliza pero en el código actual tampoco muta. Para satisfacer #8 habría que crear nuevos metadatos pero es totalmente factible crear un nuevo objeto una sola vez con los nuevos metadatos. La paso a DataClass con frozen=True. Tendré que mover alguna funcionalidad de la clase al parser.
PhraseEnd sigue el mismo razonamiento que las notas, no se da ningún caso en el que se reutilice, es deseable afinar su posición con distintas técnicas y es beneficioso mutar un PhraseEnd concreto de la lista.