Tengo una estructura de datos compuesta por trabajos que contienen cada uno un conjunto de tareas. Tanto los datos de empleo y de tareas se definen en archivos como estos:cómo leer estructuras de datos inmutables desde un archivo en scala
jobs.txt:
JA
JB
JC
tasks.txt:
JB T2
JA T1
JC T1
JA T3
JA T2
JB T1
El proceso de creación de objetos es la siguiente:
- leer cada puesto de trabajo, crear y almacenarlo por id
- tarea de lectura, recuperar empleo por id, crear tarea, almacenar tarea en el trabajo
Una vez que se leen los archivos, esta estructura de datos nunca se modifica. Entonces me gustaría que las tareas dentro de los trabajos se almacenen en un conjunto inmutable. Pero no sé cómo hacerlo de manera eficiente. (Nota: el mapa inmutable almacenamiento de trabajos se puede dejar inmutable)
Aquí es una versión simplificada del código:
class Task(val id: String)
class Job(val id: String) {
val tasks = collection.mutable.Set[Task]() // This sholud be immutable
}
val jobs = collection.mutable.Map[String, Job]() // This is ok to be mutable
// read jobs
for (line <- io.Source.fromFile("jobs.txt").getLines) {
val job = new Job(line.trim)
jobs += (job.id -> job)
}
// read tasks
for (line <- io.Source.fromFile("tasks.txt").getLines) {
val tokens = line.split("\t")
val job = jobs(tokens(0).trim)
val task = new Task(job.id + "." + tokens(1).trim)
job.tasks += task
}
Gracias de antemano por todas las sugerencias!
Me gusta este enfoque. Pero simplemente escribiría un método 'addTask' que devuelve un nuevo' Job' con los mismos datos, más la nueva tarea. Cambiaría la lógica un poco, pero, tal como está, 'Job' parece saber demasiado sobre cómo se va a inicializar. :-) –
Lo hice de esta manera para resaltar el reemplazo del trabajo anterior por uno nuevo, que me pareció ser el concepto clave aquí. Pero estoy de acuerdo en que un 'addTask' en algún lugar sería mejor. Hay muchos lugares por los que uno podría pelear (¿debería tomar una 'Opción [Trabajo]', o ser un cierre alrededor del mapa mutable?). –
Gracias, me gusta esta solución para la idea de que Job cree el nuevo trabajo (por constructor o método addTask). Todavía soy muy nuevo en Scala (vengo de Java) y todavía no estoy seguro si, en un caso como este, la inmutabilidad vale la pena el costo de tener muchos objetos creados, ya que para mí el rendimiento es bastante importante (en el caso real tengo más las 2 clases, con enlaces complejos entre ellas y miles de objetos). –