POO Aplicada a Base de Datos

[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.