Entender las aplicaciones orientadas a Objetos

"Javito" wrote in message
news:

1) En una aplicación orientada a objetos ¿ El Servidor carga todos los
objetos que necesita la aplicación cuando se inicia la misma ?

No tiene nada que ver. Lo de utilizar orientación a objetos se puede
hacer, por ejemplo, para programar un juego gráfico. No tiene por qué
existir un servidor ni cargarse ningún objeto en un servidor para que una
aplicación sea orientada a objetos.

2) ¿ Quiere esto decir que en estas aplicaciones no se accede a la Base de
Datos para realizar las operaciones, sino que se realizan sobre los
objetos en memoria ?

Eso es otra cosa. Estás pensando en un ORM (Object-Relational-Mapping),
que es un sistema en el que se "mapea" el contenido de la base de datos a
una serie de objetos en memoria. No todas las aplicaciones orientadas a
objetos tienen por qué usar necesariamente un ORM. Pero en caso de que se
use, no significa que no se acceda a la base de datos, sino que cuando se
accede, los datos de las tablas se almacenan dentro de objetos para
procesarlos más fácilmente en memoria. Lo normal es que, después de
manipular la información dentro de los objetos, se vuelva a grabar en la
base de datos.

3) Si hay varios usuarios trabajando en la aplicación y cada uno carga sus
propios objetos desde datos de la Base de datos, si tu has hecho algo en
un objeto en memoria, el que se incorpora a la aplicación al cargar los
datos desde Base de datos no va a tener tus cambios y habría
inconsistencia de datos ¿ como se evita esto ?

Cuando se trabaja así, se dice que se está usando el modelo de
"concurrencia optimista". Se asume que es muy improbable que dos usuarios
estén manipulando a la vez el mismo objeto, por lo que raramente existirá
una inconsistencia de este tipo. En los raros casos en los que se produce,
se detecta esta circunstancia porque en el momento de ir a grabar los datos
modificados se comparan los que hay en ese momento en la base de datos con
los que originalmente se leyeron. Si no coinciden, se asume que alguien los
ha modificado mientras tanto, y se resuelve manualmente la inconsistencia,
bien sea pidiendo la intervención del usuario, o bien mediante programación
en los casos en que se pueda.
Nótese que este problema se puede presentar con independencia de que se
esté usando un ORM. En un modelo tradicional en que se carguen los registros
del servidor en una simple estructura de datos en memoria, aun sin usar
orientación a objetos, existe el mismo problema de control de la
concurrencia.

Gracias Pablo, ahora ya tengo el concepto del ORM, que intuía debía de
existir pero que no sabía como se llamaba y por ello no podía estudiarlo.

Solo una consulta más, te pongo un caso corto a ver si me lo puedes aclarar
Imaginate una aplicación que permite reservar coches desde Internet y para
ella he diseñado una aplicación basada en objetos, por tanto he creado las
clases:
- Coche
- Reservas
- Cliente
- Gestor (clase que realiza todas las gestiones)

Luego desde la clase Gestor le presento al cliente el acceso al
Servicio de Alquiler de Coches, cuando el Gestor recibe la demanda accede a
Base de Datos y mete los coches disponible en un Array y los presenta, el
cliente elige uno y el Gestor le presenta la factura y le pide los datos de
la Tarjeta de Crédito y conecta a la entidad financiera para validarla, una
vez validada le confirma al cliente el Alquiler por pantalla y le envía un
Email con los datos.

Como ves después de crear 4 clases solo se ha usado el Gestor que
accediendo a Bases de datos lo hace todo, podrias cambiar algo en este guión
para que el proceso utilizara las otras clases y fuera un diseño orientado a
objetos y no una clase gorda que lo resuelve todo.

Un Saludo y te agradezco que te tomes la molestia de enseñarme


"Alberto Poblacion"
escribió en el mensaje news:

"Javito" wrote in message
news:

1) En una aplicación orientada a objetos ¿ El Servidor carga todos los
objetos que necesita la aplicación cuando se inicia la misma ?

No tiene nada que ver. Lo de utilizar orientación a objetos se puede
hacer, por ejemplo, para programar un juego gráfico. No tiene por qué
existir un servidor ni cargarse ningún objeto en un servidor para que una
aplicación sea orientada a objetos.

2) ¿ Quiere esto decir que en estas aplicaciones no se accede a la Base
de Datos para realizar las operaciones, sino que se realizan sobre los
objetos en memoria ?

Eso es otra cosa. Estás pensando en un ORM (Object-Relational-Mapping),
que es un sistema en el que se "mapea" el contenido de la base de datos a
una serie de objetos en memoria. No todas las aplicaciones orientadas a
objetos tienen por qué usar necesariamente un ORM. Pero en caso de que se
use, no significa que no se acceda a la base de datos, sino que cuando se
accede, los datos de las tablas se almacenan dentro de objetos para
procesarlos más fácilmente en memoria. Lo normal es que, después de
manipular la información dentro de los objetos, se vuelva a grabar en la
base de datos.

3) Si hay varios usuarios trabajando en la aplicación y cada uno carga
sus propios objetos desde datos de la Base de datos, si tu has hecho algo
en un objeto en memoria, el que se incorpora a la aplicación al cargar
los datos desde Base de datos no va a tener tus cambios y habría
inconsistencia de datos ¿ como se evita esto ?

Cuando se trabaja así, se dice que se está usando el modelo de
"concurrencia optimista". Se asume que es muy improbable que dos usuarios
estén manipulando a la vez el mismo objeto, por lo que raramente existirá
una inconsistencia de este tipo. En los raros casos en los que se produce,
se detecta esta circunstancia porque en el momento de ir a grabar los
datos modificados se comparan los que hay en ese momento en la base de
datos con los que originalmente se leyeron. Si no coinciden, se asume que
alguien los ha modificado mientras tanto, y se resuelve manualmente la
inconsistencia, bien sea pidiendo la intervención del usuario, o bien
mediante programación en los casos en que se pueda.
Nótese que este problema se puede presentar con independencia de que se
esté usando un ORM. En un modelo tradicional en que se carguen los
registros del servidor en una simple estructura de datos en memoria, aun
sin usar orientación a objetos, existe el mismo problema de control de la
concurrencia.

"Javito" wrote in message
news:

Gracias Pablo,

¿Quién es Pablo?

[... caso ...]
Como ves después de crear 4 clases solo se ha usado el Gestor que
accediendo a Bases de datos lo hace todo, podrias cambiar algo en este
guión para que el proceso utilizara las otras clases y fuera un diseño
orientado a objetos y no una clase gorda que lo resuelve todo.

cuando el Gestor recibe la demanda accede a Base de Datos y mete los
coches disponible en un Array

El "array" en cuestión debería ser un array de objetos de tipo Coche,
con lo que ya estás usando la clase Coche. Por cierto, "obtener un array con
los modelos de coche" es una funcionalidad que probablemente debería estar
programada dentro de la clase Coche (o Coches, si optas por el modelo que
separa elemento y colección), y no en el Gestor.

el cliente elige uno y el Gestor le presenta la factura

Cuando el Gestor le presenta la factura al cliente, necesita para ello
saber quién es el cliente para tomar sus datos para la factura. Estos datos
habrán salido de un objecto Cliente que previamente habrás sacado desde base
de datos cuando el cliente introduce sus credenciales. Por lo tanto, estás
usando la clase Cliente. Por cierto, "buscar el cliente a partir de sus
credenciales", es una funcionalidad que probablemente debería estar dentro
de la clase Cliente y no dentro del Gestor.

una vez validada le confirma al cliente el Alquiler por pantalla y le
envía un Email con los datos.

Una vez más estamos usando la clase Cliente para sacar el Email. Además
de eso, cuando se llega a este punto hay que grabar la reserva que ha hecho
el cliente, para lo cual se creará un objeto de tipo Reserva en el cual se
estabecerán las propiedades correspondientes y luego se ejecutará su función
"grábate en la base de datos".

On Sat, 25 Nov 2006 22:12:57 +0100, "Javito"
wrote:

Solo una consulta más, te pongo un caso corto a ver si me lo puedes aclarar
Imaginate una aplicación que permite reservar coches desde Internet y para
ella he diseñado una aplicación basada en objetos, por tanto he creado las
clases:
- Coche
- Reservas
- Cliente
- Gestor (clase que realiza todas las gestiones)

Luego desde la clase Gestor le presento al cliente el acceso al
Servicio de Alquiler de Coches, cuando el Gestor recibe la demanda accede a
Base de Datos y mete los coches disponible en un Array y los presenta, el
cliente elige uno y el Gestor le presenta la factura y le pide los datos de
la Tarjeta de Crédito y conecta a la entidad financiera para validarla, una
vez validada le confirma al cliente el Alquiler por pantalla y le envía un
Email con los datos.

Como ves después de crear 4 clases solo se ha usado el Gestor que
accediendo a Bases de datos lo hace todo, podrias cambiar algo en este guión
para que el proceso utilizara las otras clases y fuera un diseño orientado a
objetos y no una clase gorda que lo resuelve todo.

Se podría pero no se debería. La OO no sirve para esto, la gestión de
los datos la debe de realizar el SGBD. En un sistema de información,
las aplicaciones OO solo se deben de encargar de la comunicación y la
presentación de los datos, y para esto normalmente las únicas clases
que tienes que crear son los formularios.

El problema es que a muchos programadores esto no les resulta lo
suficientemente divertido y se dedican a reinventar la rueda cuadrada
creando clases para hacer lo que debería de hacer el SGBD.

Usar la OO para esto que pones en tu ejemplo es dar un grandísimo paso
hacia atrás. La OO es útil para otras cosas, pero catastrófica para
gestionar datos.

Aquí puedes ver lo que opina el creador de C++ sobre esto:

http://www.linuxquestions.org/revie...e/1/si/wri


http://www.dbtalk.net/microsoft-pub...82761.html

By the way, trying to use OO models in SQL is usually a disaster. Many
years ago, the INCITS H2 Database Standards Committee(nee ANSI X3H2
Database Standards Committee) had a meeting in Rapid City, South
Dakota.
We had Mount Rushmore and Bjarne Stroustrup as special attractions.
Mr.
Stroustrup did his slide show about Bell Labs inventing C++ and OO
programming for us and we got to ask questions.

One of the questions was how we should put OO stuff into SQL. His
answer was that Bells Labs, with all their talent, had tried four
different approaches to this problem and come the conclusion that you
should not do it. OO was great for programming but deadly for data.


Saludos

Gracias Alberto (... y no Pablo no sé de donde lo saqué) me aclara la
situación y así lo medio entendía, pero toda mi confusión proviene de
conversación con personas que trabajan en empresas con programas orientados
a objetos, quienes me comentan que normalmente se utilizan la mayoria de las
clases solamente como contenedores de datos, y luego se crean clases
Gestoras que llevan toda la funcionalidad, yo lo que ellos dicen lo veo como
programación estructurada disfrazada de objetos, con una clase gorda y el
resto con solo atributos, por la conversación con ellos también deduje que
debía haber algo que no conocia y que luego tu me has aclarado que se llama
ORM y a lo mejor programando en ese entorno cambia algo.

Para mi que una clase debe recoger todos los datos que se necesiten en
Atributos y todos los procedimientos que se necesite hacer con esos datos en
sus Métodos con lo cual se crean todas las clases independientes y sin
solapamientos, y luego crear un gestor como clase que invoca las funciones
de cada objeto y resuelve de forma centralizada.

Comentame si para ti es así, o hay alguna cosa más que tener en cuenta

y te agradezco sobremanera el interes que has demostrado en facilitarme la
comprensión de todo esto y sobre todo del ORM que ya he comenzado a
estudiar.

un saludo


"Alberto Poblacion"
escribió en el mensaje news:

"Javito" wrote in message
news:

Gracias Pablo,

¿Quién es Pablo?

[... caso ...]
Como ves después de crear 4 clases solo se ha usado el Gestor que
accediendo a Bases de datos lo hace todo, podrias cambiar algo en este
guión para que el proceso utilizara las otras clases y fuera un diseño
orientado a objetos y no una clase gorda que lo resuelve todo.

cuando el Gestor recibe la demanda accede a Base de Datos y mete los
coches disponible en un Array

El "array" en cuestión debería ser un array de objetos de tipo Coche,
con lo que ya estás usando la clase Coche. Por cierto, "obtener un array
con los modelos de coche" es una funcionalidad que probablemente debería
estar programada dentro de la clase Coche (o Coches, si optas por el
modelo que separa elemento y colección), y no en el Gestor.

el cliente elige uno y el Gestor le presenta la factura

Cuando el Gestor le presenta la factura al cliente, necesita para ello
saber quién es el cliente para tomar sus datos para la factura. Estos
datos habrán salido de un objecto Cliente que previamente habrás sacado
desde base de datos cuando el cliente introduce sus credenciales. Por lo
tanto, estás usando la clase Cliente. Por cierto, "buscar el cliente a
partir de sus credenciales", es una funcionalidad que probablemente
debería estar dentro de la clase Cliente y no dentro del Gestor.

una vez validada le confirma al cliente el Alquiler por pantalla y le
envía un Email con los datos.

Una vez más estamos usando la clase Cliente para sacar el Email. Además
de eso, cuando se llega a este punto hay que grabar la reserva que ha
hecho el cliente, para lo cual se creará un objeto de tipo Reserva en el
cual se estabecerán las propiedades correspondientes y luego se ejecutará
su función "grábate en la base de datos".