FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#1
|
|||
|
|||
Ayuda con el dissenyo de una aplicacion. Clases o no?
Muy buenas de nuevo, soy estudiante y tengo que realizar una aplicación. El motivo de mi mensaje es que me gustaría saber como harían el diseño de clases para la programación en Delphi i como lo harían? (Ya que nunca he trabajado con clases en Delphi, solo con los formularios, el contenedor de datos y los diferentes componentes ADO, aparte también si seria útil la utilización de clases en esta aplicación y las posibles ventajas y inconvenientes de trabajar así.) La aplicación trata de la gestión de un club de vela, Las tablas que utilizare son las siguientes:
- Socios, servicios, acompañantes, invitaciones, taquillas, embarcaciones , tipos de embarcaciones y la tabla contracta que es donde guardo los servicios contratados por el socio en la data de contratación. Donde: Los socios pueden contratar 1 o muchos servicios y estos pueden ser de ningún o de muchos socios (interesa guardar la data de contratación). Aparte los socios tienen acompañantes los cuales la cantidad vendrá determinada según el servicio escogido (en la tabla servicios hay un atributo que indica la cantidad de acompañantes y de invitaciones permitidas) y esos acompañantes serán solo de ese socio. Y lo mismo con las invitaciones. También los socios pueden contratar o ninguna taquilla o solo una, la cual esta taquilla pertenecerá a ningún socio o solo de uno (interesa guardar la data de contratación). Además los socios pueden tener ninguna o muchas embarcaciones y esa embarcación solo será de ese socio. Volviendo a las Embarcaciones, estas solo pueden ser de un único tipo y ese tipo puede pertenecer a ninguna o ha muchas embarcaciones. La aplicación la realizo en Delphi 7 i Access Espero que me haya explicado lo suficiente. Si tienen cualquier duda yo se lo vuelvo a explicar. Muchas gracias de antemano y sobretodo a Crandel por su anterior consejo! Tram. Última edición por tramjauer fecha: 02-09-2005 a las 12:28:57. |
#2
|
||||
|
||||
Yo sí utilizaría clases, pero antes debes saber los conceptos de la POO (Programación Orientada a Objetos).
Yo, desde hace un año aproximadamente, he empezado a trabajar con la POO dentro de Delphi (hasta no entonces solo usaba Programación estructurada). El buen uso de las clases te puede evitar muchos problemas, tener un código muy claro (encontrar y resolver problemas rápidamente), el uso de la herencia y polimorfismo te ayudaran a no repetir código, etc. Pero si te descuidas puede ser todo un caos, jeje. Aún me queda un largo camino, pero día a día es más fácil.
__________________
Si no lo sabes, necesitas leerlo |
#3
|
|||
|
|||
Cita:
Salu2. |
#4
|
||||
|
||||
Puedes buscar un poco por este foro con las palabras: herencia, polimorfismo, encapsulación... (ya que palabras de 3 carácteres como OOP no deja :P)
La revista Sintesis (realizada por Grupo Albor ) contiene artículos dedicados al tema en castellano. No sé, yo no he leido un manual en concreto. Siempre ha sido información de aquí y de allá. Mucho google buscando conceptos y problemas. Ahora que están de moda los blogs también saco ideas de ellos. Mi siguiente paso es entrar en una academia o algo para realizar un curso que me empape de lleno, y aprender UML.
__________________
Si no lo sabes, necesitas leerlo |
#5
|
||||
|
||||
Hola tramjauer, como te comentaba en los sistemas de este tipo, en general los accesos a las bases de datos ya estan encapsuladas en clases (con componentes), lo unico que debes hacer es utilizar los metodos para acceder a los datos.
Por otro lado tenes el diseño de las partes de tu aplicación Visualización de los datos, modificación de cada tabla y generación de reportes y demás. En general cada uno de ellos va a estar relacionado con un formulario, por lo que en general no es necesario crear nuevas clases. Sin embargo puedes separar la parte visual de los formularios creando una clase que se encargue de manipular el acceso a cada tabla (se complica mas el diseño).
__________________
[Crandel] |
#6
|
|||
|
|||
Buenas de nuevo a todos, entonces sino he entendido mal lo que me recomiendas es que mediante los componentes ya hechos haga todos los accesos a la base de datos y que el diseño de la aplicación lo divida según los formularios que tenga que hacer no?
Entonces si es así como lo entendí, me pueden decir que ventajas o inconvenientes tiene el hecho de trabajar así? Muchas gracias de nuevo. Tram. |
#7
|
||||
|
||||
Hola,
Tú mismo dices algo que tienes que replantearte: Cita:
A continuación te planteas lo siguiente: Cita:
Cita:
No es que no quiera ayudarte, entiéndeme bien, yo no me veo capaz de mostrarte las virtudes que un paradigma de programación pueda tener respecto de otro, pero, lo poco que pudiera decírsete tal vez te confundiría más aún, pues que, como he dicho, no son estas cosas para tratar de darlas cabo en unos cuantos párrafos. Espero que lo entiendas; espero haberme explicado bien. |
#8
|
|||
|
|||
Muchas gracias DEC por tu respuesta, pero creo que no m'he explique bien quando dije lo de usar los componentes de accesso a la base de datos ya hechos, ya que me referia a los que ya estan creados (es decir todos los componentes ADOTable, Datasouce, etc...).
I una duda que m'he a salido, lo que se habia planteado de usar los diferentes componentes para el acceso a la BBDD y que el dissenyo de la aplicación lo divida segun el numero de formularios, entonces la estructura de programacion que seria estructurada? o orientada a objetos? Estoy confundido en estos momentos. Lo siento. Gracias de nuevo. Tram. |
#9
|
||||
|
||||
Hola,
Cita:
Cita:
Es a la hora de hacer algo "por tu cuenta" en Delphi, cuando puedes plantearte hacerlo con una orientación a objetos en mente, o hacerlo a base de funciones y procedimientos y unidades, por ejemplo, con lo cual de seguro estarás mezclando ambos paradigmas: la orientación a objetos que es ineludible en Delphi (generalmente) y la programación estructurada que llevaras a cabo en la codificación o diseño de tu aplicación. Cuando digo que puede ser una mezcla no digo que esté mal hecho así, que conste, digo que es una forma de hacerlo. Cita:
|
#10
|
|||
|
|||
Hola.
Creo que hay una pequeña confusión, o al menos así lo percibo yo... La programación en Delphi (desde mi punto de vista) no es orientada a objetos al 100%... Por ejemplo, usar componentes DB Aware, es un tema un tanto complejo en donde encontrarás mucha diversidad de criterios. Te recomiendo que le eches un vistazo a lo que se denomina "mecanismo de persistencia de objetos" o en ingles "Object Persistent Framework"... En definitiva creo que tal ve es eso lo que preguntas. Esto consiste en trabajar a nivel de clases para la información, es decir, si manejas clientes en tu aplicación, tendras una clase TCliente con métodos para por ejemplo agregar un cliente, borrar un cliente, buscar clientes por ID, nombre... y todo lo que se te pueda ocurrir relacionados con clientes. Lo que comento de Object Presistent Framework o OPF (ver "tiOPF" en google) permite hacer esto precisamente. Esta forma de programar francamente no la he usado, pero estoy intentando leer y averiguar sobre esto, pues creo que para programas grandes es conveniente plantearse esto desde un principio. Puedes seguir la otra línea que es los componente DB Aware en el desarrollo clásico que plantea Delphi (usar TTables, TQuerys, TDataSource, TDataModule..), pero ahora te pregunto, te ha pasado que tengas que cambiar el nombre de un campo de una tabla, donde uses mucho ese campo en tu aplicación? Es tedioso de mantener. Otra opción que también he leido por ahí, y es la que estoy intentando seguir con un programa más o menos grande que estoy desarrollando es como un "hibrido", que plantea usar clases para la manipulación de datos, y poder usar DB Aware en algunas cosas. Por ejemplo la idea que tengo es usar clases principalmente para el "ingreso" de datos, y lo que son mantenimientos, usar DB Aware. Tal vez me salga el tiro por la culata y me quede con los inconvenientes de ambas técnicas . Espero que no, pero como también estoy aprendiendo sobre esto, todavía no puedo opinar con conocimiento de causa, sino dar ideas... No sé si a eso es a lo que te referías, o si te he confundido aún más. Si en algo estoy equivocado, por favor diganme. Un cordial saludo. |
#11
|
||||
|
||||
Pues yo creo que al utilizar Delphi, normalmente uno hace POO (tambien se puede hacer programación estructurada pero es diferente).
Cuando iniciamos un aplicación, Tenemos por defecto creada una clase llamada TForm1 descendiente de TForm, hay declarada una instancia de TForm1, por lo que se termina creando un objeto del mismo. Colocamos un Botón sobre nuestro formulario y y Tenemos una instancia de TButton llamada Button1 que a su vez esta contenida dentro de TForm1 (clases contenedoras). Hacemos doble click sobre nuestro Button1 y comenzamos a escribir nuestro código. Estamos escribiendo el código que será ejecutado ante un evento OnClick. No creo que esto sea programación estructurada. Lo que pasa es que Delphi nos la hace muy fácil y nos libera de un montón de cosas. Ahora tambien podemos y en muchos casos es necesario crear nuestras propias clases. Cita:
Donde en esta clase encapsulemos nuestro acceso a la base de datos, de manera que en nuestra aplicación no nos importe en que tipo de motor estamemos guardando o si estamos guardando nuestros datos en un archivo de texto. Cuando querramos modificar el lugar donde se guardan los datos simplemente modificamos esta clase y el resto de la aplicación sigue como si nada. Espero haber sido claro.
__________________
[Crandel] |
#12
|
|||
|
|||
Muy buenas de nuevo, esta manera propuesta por Crandel es la que estaba buscando y la que tenia en mente, lo que pasa es que no se como se tiene que montar esta/s clases, ya que los diferentes componentes para el acceso a la BBDD no se donde irían si en el formulario donde tengo diseñada la aplicación o si irían en la nueva clase creada (ej. TCliente). Si alguien me lo pudiera explicar bien o enviar-me algún ejemplo de como se define una clase nueva para después poder llamar a los diferentes constructores y métodos y poder así trabajar con los objetos, estaría muy agradecido. Además también donde irían los diferentes componentes para el acceso a la BBDD si en la clase TCliente o si en el diseño de l’aplicación.
Muchas gracias de nuevo. Tram. |
#13
|
||||
|
||||
Hola, recuerda que de esta forma estmos ocultando el acceso a fuente de datos (la base de datos), por lo que no pueden estar los componentes en el formulario, ni en un DataModule, tienen que estan dentro de la clase.
Es esta clase la que te tiene que servir de interfaz para cualquier acción que quieras realizar con los clientes. Lo mismo debes hacer practicamente con cada tabla. Luego dentro de las mismas clases debes comenzar a establecer las relaciones. Donde se complica un poco más es en relacionar los datos con los componentes. No es fácil, pero cuando lo terminas queda espectacular.
__________________
[Crandel] |
#14
|
|||
|
|||
Lo siento Crandel pero no te he entendido del todo bien.
Segun lo que he entendido Me dices que en el Data Module ponga la conexion , y todo lo que son AdoTablas,Adoqrys, etc. de la clase Tcliente las ponga dentro de la misma clase. NO? pero si es solo una clase no tiene formulario no?(corrigeme si me equivoco) Y entonces qualquier insercion, modificacion o eliminacion pasaran por esta clase, no? + "Luego dentro de las mismas clases debes comenzar a establecer las relaciones." ---> A que te refieres? + "Donde se complica un poco más es en relacionar los datos con los componentes." ---->Porque se complica un poco mas lo unico que se tiene que hacer es hacer uso de las diferentes clases creadas (TCliente) en el uses no? Y la estructura para declara la clase como seria? Ya que e visto de muchos tipos y ninguna igual. Y no se si se tiene que seguir alguna plantilla o que. Muchas gracias de nuevo y siento ser tan pesado!:P |
#15
|
||||||
|
||||||
Cita:
Cita:
Cita:
Cita:
Cita:
Cita:
__________________
[Crandel] |
#16
|
|||
|
|||
Muy buenas de nuevo jejeje
Haber si me queda claro de una vez: (es que me quiero asegurar) 1.- Según me dices todos los componentes (ADOConnection, ADOQry, ADOTable, etc...) van en el formulario de la clase (ej. Tcliente), no? 2.- Entonces si tengo muchas clases como es normal que tendré muchos ADOConnection? 3.- Lo de establecer las relaciones me ha quedado claro! 4.- Entonces si no tengo el Componente DataSource como accedo y muestro los datos en los formularios? Mediante los diferentes metodos? Espero que con tu respuesta se terminen mis dudas. Muchas gracias de nuevo. Tram. |
#17
|
|||
|
|||
Hola.
Cita:
Veamos un ejemplo para intentar aclarar algunas cosas, imagina un modelo entidad relación, donde tienes Clientes, paquetes y servicios. Un cliente puede adquirir 0 o 1 paquete, y un cliente puede adquirir uno o mas servicios. De esa forma, una posible implementación es que tengas por ejemplo una tabla "Clientes-Servicios" y el paquete que adquiere el cliente, lo pones como un atributo en la tabla de la transacción (relacionado con la tabla paquetes) por ejemplo "Compras". De esta forma (por ejemplo), tendrías las clase TCliente, TCompras, TServicios, TPaquetes. La clase compra tendría una propiedad que sería el cliente, o el ID del cliente. La clase TServicio, pudiese tener por ejemplo un método para buscar por precios, o por popularidad devolviendolos en un TStrings, y cosas así... Ya eso depende de lo que el problema requiera. La clase TCompra, pudiera tener un método por ejemplo para contratar un paquete, y pudiera tener métodos para contratar servicios... Cita:
Cita:
EdtNombre := Cliente.Nombre; // O Cliente.GetNombre si no usas propiedades.. EdtApellido := Cliente.Apellido; Pensandolo bien... Creo que no se pueden usar componentes DB Aware, pues todos se vinculan a un DataSource y éste sólo se puede vincular a una tabla... Sería interesante si existieran TDataSet "virtuales" que no se vinculen a la base de datos, sino que sean controladores de datos en los que tú cargas los datos como en una tabla virtual para que después puedas usarlos... Espero que te sirva y te oriente lo que te digo. Un cordial saludo, y ánimo que estamos en las mismas |
#18
|
|||
|
|||
Buenas, me parece que no m’he has entendido o lo has leído mal:
- No necesariamente tendrás un formulario para cada clase. Hablamos de clases "a lo bestia" jeje . La clase TCliente no es un formulario, es una entidad de datos (o conjunto de datos), es como si fuera una simulación de una tabla clientes de tipo TDataSet, pero con métodos propios.à Ya lo se que la clase TCliente no es un formulario, lo que yo preguntaba es que si todos lo componentes ADO van en la clase (como habia dicho el amigo Crandel), digo yo que se tendrán que poner en un formulario no¿? I sino donde? - Entonces si tengo muchas clases como es normal que tendré muchos ADOConnection? à Entonces según tu la conexión ira como siempre en el dataMolule no¿? - Por todo lo demas muchas gracias. Tram. |
|
|
|