Programación orientada a objetos

On Wed, 17 Jan 2007 17:16:57 +0100, "Javito"
wrote:

Estoy un poco confuso porque después de un curso de UML veo que se
tratan los objetos como si por cada tipo de interacción se fuera a crear un
objeto, por ejemplo si quiero diseñar un sistema de reservas de hotel, se
crea una clase Reserva que luego presumiblemente va a recoger todos los
objetos Reserva en memoria y lo mismo para Clientes etc.

Pues has hecho un curso muy malo.

Pero no veo la estructura que va a mover eso en memoria de forma rápida,
como no sea a base de Colecciones (ArrayList, Hashtable etc.) además si es
una aplicación compartida Clente-Servidor como hago para que la base de
datos no cambie mis datos mientras lo tenga en memória, puedo estar
concediendo reservas que ya alguien cambió en memoria.

La aplicación no debe de gestionar los datos en memoria, solo debe de
enviar ordenes para que el SGBD se encargue de gestionar los datos.

Esto te lo dicen en el primer capítulo de cualquier libro de bases de
datos, pero la mayoría de los profesores de los cursos de UML nunca
han leido ninguno.


Saludos
Alfredo

"Javito" wrote in message
news:%

Pero no veo la estructura que va a mover eso en memoria de forma
rápida, como no sea a base de Colecciones (ArrayList, Hashtable etc.)

No necesariamente. Puedes tener los datos en base de datos y manipularlos
uno a uno en memoria según sea necesario. Por ejemplo, un objeto Cliente
tendrá un método Leer y otro Grabar, de forma que con Leer te lo traes desde
la base de datos a memoria, lo usas y modificas como sea necesario, y luego
llamas al método Grabar para devolver los datos a base de datos.

además si es una aplicación compartida Clente-Servidor como hago para que
la base de datos no cambie mis datos mientras lo tenga en memória, puedo
estar concediendo reservas que ya alguien cambió en memoria.

Tienes que decidir si deseas usar concurrencia optimista o pesimista. Es
más corriente usar la concurrencia optimista, que consiste en leer los datos
a memoria y no hacer nada en la base de datos (con lo que alguien podría
modificarla mientras tanto). En el momento de ir a grabar, se inicia una
transacción y se vuelve a leer el registro (lo cual lo bloquea en la base de
datos), se compara con el que leímos la primera vez (que habremos guardado
en memoria) y si no ha cambiado nada (que será lo más habitual), grabamos
nuestros cambios y terminamos la transacción. Si por el contrario
encontramos que algo ha cambiado, le mostramos un mensaje de error al
usuario del estilo de "lo sentimos, pero no se pueden grabar los datos
porque mientras tenías este registro en la pantalla, alguien lo ha
modificado desde otro terminal".
Si optas por usar concurrencia pesimista, añade un campo adicional en
los registros de la base de datos que sea "en uso". Cuando leas un registro
en un terminal pones a true ese campo en la base de datos, y si alguien lo
intenta leer desde otro puesto y se lo encuentra a true, le das un mensaje
de error diciendo que ese registro está en uso desde otro puesto. Cuando la
información se graba desde el puesto que la bloqueó, se pone false en el
campo "en uso". Hay que preveer un mecanismo de limpieza de ese campo por si
algún puesto se apaga mientras tiene un registro en uso.

Yo tambien he visto en ejemplos incluso de .NET en video de microsoft, que
usan un DataSet para un esquema desconectado, para ello trayendo muchos
datos innecesarios a memoria. Tambien pienso que muchos de los cursos que
se ven por ahi como que no son muy practicos para el clasico tema de manejo
de base de datos que debe tener en cuenta la constante concurrencia y sobre
todo mantener la integridad de los datos.

Ana


"Javito" wrote in message
news:%

Estoy un poco confuso porque después de un curso de UML veo que se
tratan los objetos como si por cada tipo de interacción se fuera a crear
un objeto, por ejemplo si quiero diseñar un sistema de reservas de hotel,
se crea una clase Reserva que luego presumiblemente va a recoger todos los
objetos Reserva en memoria y lo mismo para Clientes etc.

Pero no veo la estructura que va a mover eso en memoria de forma
rápida, como no sea a base de Colecciones (ArrayList, Hashtable etc.)
además si es una aplicación compartida Clente-Servidor como hago para que
la base de datos no cambie mis datos mientras lo tenga en memória, puedo
estar concediendo reservas que ya alguien cambió en memoria.

un saludo

Pero entonces para que unir las clases con asociaciones y establecer las
multiplicidades si nunca se van a traer dichos datos a memoria, en UML
pintas todas las clases del desarrollo y estableces las asociaciones con su
multiplicidad, y todo eso es solo teoria ? luego no se aplica ?.

un saludo
"Alfredo Novoa" escribió en el mensaje
news:

On Wed, 17 Jan 2007 17:16:57 +0100, "Javito"
wrote:

Estoy un poco confuso porque después de un curso de UML veo que se
tratan los objetos como si por cada tipo de interacción se fuera a crear
un
objeto, por ejemplo si quiero diseñar un sistema de reservas de hotel, se
crea una clase Reserva que luego presumiblemente va a recoger todos los
objetos Reserva en memoria y lo mismo para Clientes etc.

Pues has hecho un curso muy malo.

Pero no veo la estructura que va a mover eso en memoria de forma
rápida,
como no sea a base de Colecciones (ArrayList, Hashtable etc.) además si es
una aplicación compartida Clente-Servidor como hago para que la base de
datos no cambie mis datos mientras lo tenga en memória, puedo estar
concediendo reservas que ya alguien cambió en memoria.

La aplicación no debe de gestionar los datos en memoria, solo debe de
enviar ordenes para que el SGBD se encargue de gestionar los datos.

Esto te lo dicen en el primer capítulo de cualquier libro de bases de
datos, pero la mayoría de los profesores de los cursos de UML nunca
han leido ninguno.


Saludos
Alfredo

Ya pero yo estoy haciendo un programa de reservas de plazas de hotel, que
ventaja me reporta que las reservas sean objetos de la clase reserva o que
obtenga lo que necesito directamente de la base de datos, de verdad que no
termino de ver la utilidad de la programación orientada a objetos, es un
capricho de alguien o que se gana con ello

un saludo
"Alberto Poblacion"
escribió en el mensaje news:uVZ$

"Javito" wrote in message
news:%

Pero no veo la estructura que va a mover eso en memoria de forma
rápida, como no sea a base de Colecciones (ArrayList, Hashtable etc.)

No necesariamente. Puedes tener los datos en base de datos y
manipularlos uno a uno en memoria según sea necesario. Por ejemplo, un
objeto Cliente tendrá un método Leer y otro Grabar, de forma que con Leer
te lo traes desde la base de datos a memoria, lo usas y modificas como sea
necesario, y luego llamas al método Grabar para devolver los datos a base
de datos.

además si es una aplicación compartida Clente-Servidor como hago para que
la base de datos no cambie mis datos mientras lo tenga en memória, puedo
estar concediendo reservas que ya alguien cambió en memoria.

Tienes que decidir si deseas usar concurrencia optimista o pesimista.
Es más corriente usar la concurrencia optimista, que consiste en leer los
datos a memoria y no hacer nada en la base de datos (con lo que alguien
podría modificarla mientras tanto). En el momento de ir a grabar, se
inicia una transacción y se vuelve a leer el registro (lo cual lo bloquea
en la base de datos), se compara con el que leímos la primera vez (que
habremos guardado en memoria) y si no ha cambiado nada (que será lo más
habitual), grabamos nuestros cambios y terminamos la transacción. Si por
el contrario encontramos que algo ha cambiado, le mostramos un mensaje de
error al usuario del estilo de "lo sentimos, pero no se pueden grabar los
datos porque mientras tenías este registro en la pantalla, alguien lo ha
modificado desde otro terminal".
Si optas por usar concurrencia pesimista, añade un campo adicional en
los registros de la base de datos que sea "en uso". Cuando leas un
registro en un terminal pones a true ese campo en la base de datos, y si
alguien lo intenta leer desde otro puesto y se lo encuentra a true, le das
un mensaje de error diciendo que ese registro está en uso desde otro
puesto. Cuando la información se graba desde el puesto que la bloqueó, se
pone false en el campo "en uso". Hay que preveer un mecanismo de limpieza
de ese campo por si algún puesto se apaga mientras tiene un registro en
uso.