dudas respecto a poo

[moron]

Consulta:

si la clase libro recibe una lista de id's de autores que fueron seleccionados de una lista en el navegador web, en el metodo ingresarAutores() que carga los autores en una tabla libro_has_autores (idlibro,idAutor).

con que sentido creo n objetos autores dentro de libro (segun experto) para setearle a cada uno el id si luego lo unico que voy a hacer es obtener nuevamento los id para enviar a la clase de persistencia asociarAutoresALibro(idLibro,idAutor).

seguro hay algun argumento de la poo que se me escapa o estoy haciendo algo mal.

Otra cosa, en este mismo caso, siendo que los autores estan en una tabla de la base de datos, tiene sentido llamar a la clase fachada de persistencia para que me traiga todos los autores convertidos a objeto con sus respectivos datos para hacer el insert?


muchas gracias desde ya

[guille_el3]

Ahhh, disculpa pero me duelen los ojos despues de ver lo que has escrito!!!!

1) el paradigma de objetos esta basado en objetos, no en clases.
2) no estas pensando en objetos sino en alguna cosa loca que no se...

Te cuento lo que yo haria en tu caso:

a) no le mandaría una coleccion de ids a la clase libro. Tendria un objeto libro, que entenderia el mensaje (tendria el metodo para los poco entendidos) agregarAutor(unAutor).

ese objeto libro no deberia de recibir el id del autor, sino el autor completo, que podrias instanciar antes. Y no le mandaria una coleccion/array/loQueSea sino que le mandaria uno por uno.

b) Normalmente uno usa objetos porque esos objetos hacen algo, si tus objetos no hacen nada, es obvio que le veas poca utilidad a ir a buscarlos a la base. Fijate si no hay cosas que deberian hacer tus objetos que estas hciendo tu en tu script/loQueSeaQueUsesEnElLenguajeQueProgrames, y en ese caso ya tienes algo....

En cuanto a la duda de persistencia en sí, si estas diseñando un sistema web, es obvio que tus objetos son descartables, los buscas en la base y los tiras... Si buscas a tus objetos para que ellos hagan algo entonces sí tiene sentido ir a buscarlos, sino no.... O no se, depende como plantees tu sistema...

Suerte!

[moron]

Gracias por la respuesta.

"ese objeto libro no deberia de recibir el id del autor, sino el autor completo, que podrias instanciar antes".

Es que me baso en los patrones creador y experto y segun creador, debería ser libro quien crea(instancia) autores ya que es quien los contiene o hace algo con ellos, es por eso que le paso un id para que lo cree, (porque desde alguna interfaz que puede ser web, el usuario elige una serie de autores para insertar) y luego si, los va cargando como objetos en una lista de autores.
es decir,
El id lo uso como un OID para persistencia, libro recibe una lista de OID (object id), instancio persistencia dentro de libro y por cada uno de los OID lo envio a persistenciaBDR, quien devuelve un objeto autor desde bd, archivo o lo que fuere, y los voy metiendo en una lista de autores dentro de libro.
Que habría de malo si en lugar de instanciar el autor antes de pasarselo a libro, este se instancie en libro y se agregue a si mismo el/los autores?
Creo que además es una forma de desacoplar los objetos y no cargar de responsabilidad a algunos objetos de mas

[guille_el3]

Iniciado por moron

Creo que además es una forma de desacoplar los objetos y no cargar de responsabilidad a algunos objetos de mas

Justamente estas acoplando más los objetos. Estas asignando responsabilidades al libro que no son de él. ¿Porque tiene el libro que encargarse de conectarse con la base de datos? O sea si quieres tener objetos que cumplan el patron de "creator" o "experto" que no conozco (sí conozco patrones creacionales como builder, factory, singleton) tenlos, pero que no sea el libro.

El acoplamiento es una forma de medir el grado de relacion entre varios objetos. Si tu libro es quien instancia a los autores, entonces decimos que estan muuy acoplados los libros con los autores, pues en tu libro hay muchas lógicas distintas, entre ellas:
a) como estan formados los autores
b) como es tu esquema de persistencia
c) no es independiente de tu capa de presentacion donde utilizas los ids o Oids.

Lo que yo haria es oootro objeto que se encargue de la persistencia, y que el libro solo reciba autores. De esa manera el libro sí esta desacoplado y el acoplamiento ahora va a estar en quien persiste porque es él quien va a saber como estan formados los autores. Por lo menos así tus autores mañana pueden cambiar sin que los libros se enteren.

Y no es cuestión de escribir más o menos codigo. Lo importante es que son unidades lógicas distintas, probablemente con reglas distintas cada uno. Si le sumas responsabilidades que no son propias el dia de mañana esos objetos van a ser incomprensibles... Y yo prefiero tener muchos mas objetos a eso.

Espero que se haya entendido algo :P
Suerte!

[moron]

Gracias por los consejos.

El patrón experto indica que quien debe realizar una operación es quien "sabe" como hacerla y creador indica que un objeto es instanciado por la clase que lo contiene.

Libro no se conecta a la base de datos, tengo una capa de persistencia, en donde libro le pide a esa capa que le devuelva un objeto autor desde bd

en libro:
conversorAutorBDR.getAutor(idAutor)

segun lo que me aconseja es dejar esta taréa a una especie de controlador?
algo asi?

controlador:

para cada autor:

autor:= conversorAutorBDR.getAutor(id) //(pongo id pq no se me ocurre otra forma de traer un autor desde un navegador web)
libro.setAutor(autor)

fin para

libro.persistirAutores()

fin controlador

gracias por la paciencia.

[guille_el3]

No se si llamarlo controlador.
Yo estoy haciendo algo así y le veo olor a objeto "caso de uso" pues controla un caso de uso de mi sistema y es quien comunica a la capa de persistencia con mi modelo e interactua con ellos :).

Una sola aclaración acerca del patron "creator". Tu libro no es quien instancia a los autores, quien los instancia es justamente el objeto ese "conversorAutorBDR" así que si bajamos a detalle no estas cumpliendo con ese "patrón" y acoplando libros con tu esquema de persistencia.

Suerte! :)

[moron]

Tenés razón acerca del patrón creador, no me habia dado cuenta, y me gusta la idea de caso de uso. lo voy a hacer de esa forma, de paso me queda la clase con el mismo nombre que en el caso de uso y la documentación.

Gracias por todo hermano, un abrazo