Entender las aplicaciones orientadas a Objetos

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

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

"Javito" wrote in message
news:%

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

Efectivamente, esa es la idea de la orientación a objetos: El objeto
contiene los datos más los métodos que operan sobre dichos datos.

Gracias Alfredo analizaré el texto que me indicas, pero lo cierto es que
conforme voy hablando con gente de la orientación a objetos me voy dando
cuenta de que cada uno lo interpreta a su manera y no hay una definición
clara de cuando usar objetos y cuando no, y sobre como se utilizan esos
objetos, ni siquiera de la razón por la que reemplazar la estructurada con
objetos,

obtengo respuestas de todos los colores, per si te puedo decir que
con toda esa información al final podré llegar a una conclusión y que toda
vuestra ayuda me habrá llevado a ello, por lo que te reitero las gracias y
leeré con interes los datos de tu referencia.

Hola Javito,


On Sun, 26 Nov 2006 18:26:37 +0100, "Javito"
wrote:

Gracias Alfredo analizaré el texto que me indicas, pero lo cierto es que
conforme voy hablando con gente de la orientación a objetos me voy dando
cuenta de que cada uno lo interpreta a su manera y no hay una definición
clara de cuando usar objetos y cuando no, y sobre como se utilizan esos
objetos, ni siquiera de la razón por la que reemplazar la estructurada con
objetos,

Tienes toda la razón. El mundo de la OO es caótico ni siquiera hay
consenso en lo que son clases y objetos.

En la OO no hay casi nada nuevo, como mucho la herencia. Lo mejor para
entender la OO es verla desde el punto de vista de la programación
estructurada clásica, que es mucho más seria. Casi todos los conceptos
de la OO son viejos conceptos renombrados o mezclados.

obtengo respuestas de todos los colores, per si te puedo decir que
con toda esa información al final podré llegar a una conclusión y que toda
vuestra ayuda me habrá llevado a ello, por lo que te reitero las gracias y
leeré con interes los datos de tu referencia.

Bueno, ahí no había muchos datos, solo las conclusiones de los
laboratorios Bell de que la OO es buena para la presentación pero
mortal para la gestión de datos.

Aquí tienes una referencia con muchos artículos interesantes sobre OO
y datos: www.dbdebunk.com


Saludos
Alfredo