POO Aplicada a Base de Datos

[Jvilomar]

Saludos mi Gente de Club Delphi.

Bueno espero haber posteado este mensaje en el foro adecuado, si no es asi mil disculpas.

Hace unos dias estuve observando unos trozos de codigos de uno de mis aplicaciones y pensando en todo el rollo de POO que eh escuchado me eh decidido a mejorar tanto en Rendimiento, como en LImpieza todas mis aplicaciones utilizando la POO. El asunto es que tengo la idea... pero no se como implementarla . Que quiero hacer? pues tengo unas clases TClientes, TApartamentos y TVehiculos siendo Tclientes mi ClaseBase y TApartamentos y TVehiculos heredan de esta... ahora el punto es que lo que quisiera es por ejemplo utilizarlas en digamos para manejar una base de datos. estoy perdido porque como veran soy muy novato en estos asuntos de POO. Me eh tirado todo el capitulo de Clases y Objetos de la ayuda de Delphi y me ha ayudado mucho.. pero como dirian, una cosa es con Guitarra y Otra con Violin .

Bueno solo pido una pequeña idea de como implementar esto que eh planteado utilizandolas para una aplicacion de Base de Datos. Perdonen si me eh enrollado pero basicamente eso es lo que me eh planteado.

Muchas Gracias por tomarse su tiempo aunque sea solo para leer este post...,

JOSE MANUEL...

PD: por cierto utilizo Delphi y y SQL Server 2000

[Neftali [Germán.Estévez]]

Tema interesante, pero muy extenso.
Tal vez deberías ser un poco más concreto.

Por ejemplo, lo primero que me llama la atención es:

Empezado por Jvilomar

...tengo unas clases TClientes, TApartamentos y TVehiculos siendo Tclientes mi ClaseBase y TApartamentos y TVehiculos heredan de esta...

Tal vez como prueba esté bien; Pero no acabo de ver claro que los vehículos y los apartamente deriven de los clientes...

Siguiendo con la pregunta...

Yo en éstos casos distingo dos partes, la parte visual y lo que es el modelo de negocio (las Clases TCliente, TVehículo,...) y los programo por separado.

Mi primera recomendación es que crees una clase base (TClaseBase, por ejemplo) de la cual deriven todas (y que sea abstyracta, es decir, que no tenga lógica de negocio, por lo tanto TCliente no sirve como clase base...), y en esa clase añadas los métodos que vas a necesitar; Por ejemplo, Grabar, Recuperar, Clonal, Limpiar, Crear, Destruir, Buscar, refrescar,...
Los que haga falta que sean virtuales y/o abstractos los defines como tales.
Eso te dará una idea y te obligará a formar un modelo de tus clases de negocio.

Lo segundo (que no comentas) es cómo vas a mapear las clases en Base de Datos. Que es otra cosa importante que debes tener claro. Hay varias estratégias; Debes decidir cual quieres. Las más comunes son (basándome en el ejemplo de que TApartamento deriva de TCliente):
* Tabla TblCliente con los campos de la clase TCliente y TblApartamento con los campos de TCliente y TApartamento.
* Tabla TblCliente con los campos de la clase TCliente y TblApartamento con los campos de TApartamento que no están en TCliente.

Si busca documentación sobre ésto (Scott Ambler es referencia obligatoria) encontrarás las ventajas/inconvenientes de cada modelo.
http://www.agiledata.org/essays/mappingObjects.html
http://www.agiledata.org/essays/umlD...ngProfile.html
http://www.service-architecture.com/...to_tables.html

http://www.agiledata.org/essays/mapp...ingInheritance

A partir de ahí y con ésta decisión puedes comenzar a implementar métodos básicos; Por ejemplo un buen comienzo es el Insert de una Clase. Si te lo "curras" un poco podrás hacer por ejemplo que el TBaseClase.Insert() te haga los INSERT de todas lasa clases sin necesidad de Redefinirlo (ahí está la potencia de la herencia).

...

[Jvilomar]

Gracias Neftali... a ver por parte:

Lo primero es que puedo tener Clientes que compren Apartamentos y Clientes que compren Vehiculos, asi el tener que tomar todos los datos generales de un cliente para realizar una venta de un apartamento, seria algo muy tedioso si puedo heredar de una clase clientes estos datos (Nombres,Ubicacion,Datos de localizacion,Referencias, etc.) y en mis clases heredadas solo me limito a los datos coherentes a dicho renglon, no es lo mismo el tipo de Apartamento o cantidad de habitaciones, que la marca del vehiculo o si es automatico o mecanico para poner un ejemplo.

Lo segundo: si quiero evitar obviamente la redundancia de datos en mi codigo y tomando en cuenta lo que ya te eh explicado en el parrafo anterior, la ultima opcion de las dos que me has presentado es lo que mas se asemeja a lo que quiero hacer: mi Tabla Cliente con los Datos Generales y mi tabla Apartamentos con los datos pertinentes... asi por ejemplo aprovecho y un cliente puede tener varias Viviendas e incluso Viviendas y Vehiculos.

Solo un ultimo punto.. las Clases Abstractas segun lei en la ayuda son aquellas que se declaran pero que no tienen ningun codigo para implementar o mejor dicho que sirven para derivar de esta (Estoy en lo correcto?). lo de las virtuales es que aun no logro digerir muy bien. De todos modos voy a darle una miradita a los links recomendados.

Gracias otra vez por responder y espero seguir investigando a ver si por fin despego definitivamente en este asunto que se me ha hecho tan interesante y casi no me deja dormir.....

Atentamente,

Jose Manuel

[Neftali [Germán.Estévez]]

Empezado por Jvilomar

Lo primero es que puedo tener Clientes que compren Apartamentos y Clientes que compren Vehiculos, asi el tener que tomar todos los datos generales de un cliente para realizar una venta de un apartamento, seria algo muy tedioso si puedo heredar de una clase clientes estos datos

Creo que deberías tener una relación entre las clases Apartamentos y Vehiculos hacia la tabla Clientes; Es una cuestión de diseño. Eso es una asociativa, no una herencia.

Empezado por Jvilomar

Lo segundo: si quiero evitar obviamente la redundancia de datos en mi codigo y tomando en cuenta lo que ya te eh explicado en el parrafo anterior, la ultima opcion de las dos que me has presentado es lo que mas se asemeja a lo que quiero hacer: mi Tabla Cliente con los Datos Generales y mi tabla Apartamentos con los datos pertinentes... asi por ejemplo aprovecho y un cliente puede tener varias Viviendas e incluso Viviendas y Vehiculos.

Revisa atentamente la documentación que te he pasado. Esa opción es la más costosa en cuanto a construcción y un poco más lenta que el resto a la hora de hacer inserciones y consultas (ya que implica más join's), pero por contra es la más "purista" en cuanto a orientación a objetos y las más versátil y sencilla de actualizar (a la hora de cambios y amplicaciones) respecto a las otras.

Empezado por Jvilomar

...las Clases Abstractas segun lei en la ayuda son aquellas que se declaran pero que no tienen ningun codigo para implementar o mejor dicho que sirven para derivar de esta (Estoy en lo correcto?). lo de las virtuales es que aun no logro digerir muy bien. De todos modos voy a darle una miradita a los links recomendados.

Aquí hay dos cosas, espero que no las liemos..
* Clase Abstracta: Nos referimos a una clase que no tiene correspondecia de un objeto real en la Base de Datos; Es decir, si tienes Triangulos(T), Circulos(C) y Elipses(E), seguramente te interesará crear una Clase Objeto2D del cual deriven el resto. Al la hora de crear/pintar objetos reales, ninguno será de la clase Objeto2D, sino que serán T, C o E.
El error está en decir que la clase abstracta no tiene código a implementar; ¡Todo lo contrario! en una estructura como esta, todo el código común que puedas programar en Objeto2D (y que sirva para sus descendientes, T, C y E) te evitarás programarlo en sus tres descendientes; Esa es la gracia, programar lo más pòsible en la clase base (Objeto2D) para evitar programarlo en las n clases descendientes.

* Métodos Abstractos/Virtuales: Son métodos de una clase y esto será lo que te ha llevado a confusión; Aquí sí es cierto que un método abstracto no tiene código.
Se define un método abstracto (vacío), para "obligar" a que todos sus descendientes lo redefinan (sobreescriban) y en la clase donde se define estará vacío.
Se define un método como virtual (vacío o con código), para permitir (no obligar) que sus descendientes lo redefinan(sobreescriban) si lo creen conveniente y necesario.

Espero haberme explicado bien.

Un saludo.

[Jvilomar]

Empezado por Neftali

Creo que deberías tener una relación entre las clases Apartamentos y Vehiculos hacia la tabla Clientes; Es una cuestión de diseño. Eso es una asociativa, no una herencia.

pues si..es correcto.. pero una relacion en cuanto a mi base de datos, y una asociacion en cuanto mis clases?

Empezado por Neftali

Revisa atentamente la documentación que te he pasado. Esa opción es la más costosa en cuanto a construcción y un poco más lenta que el resto a la hora de hacer inserciones y consultas (ya que implica más join's), pero por contra es la más "purista" en cuanto a orientación a objetos y las más versátil y sencilla de actualizar (a la hora de cambios y amplicaciones) respecto a las otras.

creo que debi estudiarme la documentacion que me facilitaste antes de responderte.. porque sinceramente me ilustro mucho en cuanto a lo que esta pasando por mi mente ahora mismo. y sobre todo la parte de los cuatro tipos de Mapeos desde un Objeto a una tabla y me ha servido de mucho de verdad.. gracias por los links..estan muy buenos.

en cuanto a la parte de las Clases Abstractas y los Metodos Abstractos y Virtuales ahora fue que comprendi perfectamente el punto. Creo que con todo esto puedo comenzar a modelar lo que necesito y lo que quiero hacer.

Gracias por Todo Neftali.

Cuando yo sea grande quiero ser como tu

y como Jachguate, Cadetill, Roman, etc..etc..etc.