Re: Pregunta j

188 views
Skip to first unread message

Adeodato Simó

unread,
Jan 25, 2021, 8:40:32 AM1/25/21
to fiuba-75...@googlegroups.com

Hola,

buenas tardes dato, estabamos intentando empezar el tp2, pero estamos sintiendo una cosa, en principio se nos ocurre tener structs de muchas cosas y eso como martin bien dijo no queda bien, pensabamos en la idea de tener tdas para esas cosas, y estamos notando que no sirven mas que para camuflar lo de los structs, no se si me explico bien.

ejemplo, struct especialidad, donde uno de sus miembros tranquilamente es un diccionario, donde tiene el nombre de una especialidad, y sus doctores

yo podria crear una primitiva que sea obtener doctor, y su unica linea seria return obtener(nombre_especialidad, doctor), o sea literalmente estoy usando una linea para usar una primitiva del tda diccionario

segundo ejemplo, si un doctor fuera un tda, donde sus miembros pueden ser, la especialidad y el numero de pacientes que atendieron una primitiva seria atender_paciente, donde su unica linea es hacer doctor->nro_pacientes++ estoy literalmente “camuflando” debajo de un supuesto tda, las llamadas con flechitas en mis structs de doctor, especialidad, y las que sea que tenga

mi consulta es, si ustedes estan esperando que usemos los tdas para esto, brindar simplemente funciones para barbara, aunque luego en el fondo estemos llamando a otros tdas o haciendo cosas muy elementales internamente

sentimos tentadora la idea de llenar de structs todo, y solo almacenar cosas en sus miembros, ya que notamos que al crear tdas, sus funciones en el fondo solo acceden a lo que haya en el struct, quiero saber si de todos modos esta bien crear tdas asi o si hay algo que nos estamos perdiendo, lo pregunto antes de caer en una reentrega muy grande

Es una pregunta válida, y tus observaciones son razonables.

En esta materia ocurren dos cosas: de un lado, solo nos da tiempo a rozar por encima lo que son cuestiones de diseño elegante para combinar todas las entidades de un programa (con entidades me refiero a doctores, clínicas, etc.)

Por otra, ocurre que los TDA (o TAD) a los que dedicamosmás de la mitad de la materia son… eso, tipos abstractos de datos. Este es un concepto muy amplio, pero lo que estoy queriendo decir es que todo lo que han implementado hasta la fecha son TDAs que almacenan cosas, y que son muy “unitarios/discretos” (hacen una sola cosa).

Hasta aquí la filosofía.

En términos prácticos, yo les recomiendo:

  • tengan en zyxcba.c solamente la función main(), y un #include "zyxcba_lib.h"
  • a donde todes invariablemente se pierden (y es la mayor lección que esperamos [o espero; esta es mi opinión] que se lleven del TP2) es que esa biblioteca de apoyo (el archivo separado zyxcba_lib.c), piensan que debe exportar varios TDA
  • explico: mucho de lo que estás describiendo arriba es porque el concepto de TDA lo estamos aplicando a algo como doctor: el nivel de granularidad es demasiado fino. En este TP, se puede considerar perfectamente que la única entidad “digna” de serle exportada a Barbara, es un TDA Clínica. En mi opinión, ver un “doctor_crear” en zyxcba.c… es un fracaso (otres docentes podrán no estar de acuerdo). Habrá un clinica_crear() que, seguramente, tomará los archivos csv, y luego primitivas adecuadas para cada uno de los comandos; no para manejar las estructuras internas.
  • y mientras ¿qué ocurre en zyxcba_lib.c? bueno, ahí habrá obviamente un struct clinica {...} (que en el .h habrá un struct clinca; sin los miembros); pero, por supuesto, en zyxcba_lib.c habrá muchos más structs (doctor, paciente, etc.) que no se veran ni por asomo (?) en el .h
    • entonces si el struct doctor es interno a la biblioteca y Barbara no lo ve, no necesitas un doctor_crear() o un doctor_atender(). la función hipotética clinica_atender() manipulará el struct que corresponda.
  • pero una última cosa que ayuda a pensar en estas cosas es: ¿podría ser que el programa siguiera creciendo y lo que es hoy una línea, pudieran ser muchas? quizás en algún momento el programa deje de trabajar con texto y se conecte a una base de datos remota… y las operaciones puedan ser más complicadas.
    • pero en ese caso, esos “TDAs complejos” nuevos (un doctor que tenga mucho más código) no necesariamente serían visibles para Barbara, sino que estarían por ejemplo en un zyxcba_doctor.c, solo visible para zyxcba_lib.c, y no para main() [*noo* en este TP; en este TP son solo dos niveles, main y lib]

Bueno espero que esto pueda aclarar algo y ayude al resto de compañeras.

¡Saludos!

-d

Reply all
Reply to author
Forward
0 new messages