Ayuda con el dissenyo de una aplicacion. Clases o no?

[tramjauer]

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.

[DarKraZY]

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.

[MasterXP]

Empezado por DarKraZY

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.

DarKraZY, como tu estabas antes estoy yo ahora, que solo hago programacion estructuradas, y la verdad es que repito bastante codigo.... si tienes algun manual, pagina web, o lo que sea de como empezar con las clases, herencia y polimorfismo.....

Salu2.

[DarKraZY]

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.

[[Crandel]]

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

[tramjauer]

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.

[dec]

Hola,

Tú mismo dices algo que tienes que replantearte:

Empezado por tramjauer

Ya que nunca he trabajado con clases en Delphi, solo con los formularios, el contenedor de datos y los diferentes componentes ADO (...)

El formulario, el contenedor de datos y los diferentes componentes ADO son objetos, o sea clases, o sea componentes. ¡Fíjate si has trabajado con clases, aunque no lo supieras, desde el mismo momento en que comenzaras a utilizar Delphi!

A continuación te planteas lo siguiente:

Empezado por tramjauer

(...) 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?

A lo primero se me ocurre decirte que, desde luego, llevar a cabo componentes propios para acceder a la base de datos que sea no debe ser una tarea sencilla... además que ya los tienes hechos, aprovéchalos, pues. En cuanto al diseño de la aplicación es algo que tienes que plantearte con cuanto cuidado puedas, pero, depende tanto de la misma que no sé hasta qué punto podrá ayudársete en ello a bote pronto: quizás Al González podría echarte una mano: ponte en contacto con él, si lo ves oportuno.

Empezado por tramjauer

(...) me pueden decir que ventajas o inconvenientes tiene el hecho de trabajar así?

Si lo que quieres decir es que te interesaría conocer las ventajas del paradigma de la programación orientada a objetos respecto del de la programación estructurada... me temo que no es tarea sencilla de explicar en unos cuantos párrafos... ¿Porqué no buscas información (en estos mismos Foros, sin ir más lejos) en relación a los temas que te preocupan? Libros que traten sobre estos temas tampoco estarían demás, ni mucho menos, así como los artículos, tutoriales y otros textos que pudieras conseguir.

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.

[tramjauer]

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.

[dec]

Hola,

Empezado por tramjauer

(...) 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...).

Claro está. Lo que yo he querido respecto de este tema es que crear ese tipo de componentes, vamos, unos que fueran capaces de sustituirlos, quizás haciendo mejor algunas tareas, desde luego, no es baladí, sencillo, simple, vaya, algo que se pueda hacer en un rato, como aquel que dice. Precisamente lo bueno es que puedes usar los que ya encuentras hechos a tu disposición.

Empezado por tramjauer

(...) 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?

Bien podría ser una mezcla de ambos paradigmas de programación. Una cosa tienes que tener clara: aunque no tengas idea de lo que es una clase, esto es, a la hora de diseñarla, construirla e instanciarla en objetos, cuando te sea preciso, trabajar con Delphi significa trabajar con objetos: toda la VCL está ahí para no desmentirme: Delphi parte de ahí, entre otras cosas, no en vano el lenguaje de que haces uso, a fuer de Delphi, se llama "Object Pascal", esto es, Pascal por añadidura orientado a objetos.

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.

Empezado por tramjauer

Estoy confundido en estos momentos. Lo siento.

No tienes que sentirlo en absoluto, quiero decir, en cuanto a mí respecta o respecta a tus dudas aquí: es cuestión de informarse uno, leyendo, sobre todo, practicando y dándole unas cuantas vueltas al tema en la cabeza, para que al cabo termines haciendo las cosas como mejor te parezca. No podrás hacerlas de un modo que no sepas, eso no te pasa a ti solo, y de ahí que te aconsejara (muy atrevidamente, porque quién soy yo para aconsejar a nadie nada) que leyeras cuanto más pudieras sobre el tema, puesto que, de otro modo, en lo que mí se refiere, no iba sino a confundirte más aún... y no se trata de eso, ¿no te parece?

[adlfv]

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.

[[Crandel]]

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.

Empezado por Crandel

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

Explicando lo que comente antes, podriamos diseñar una clase llamada TClientes, de la siguiente forma:

Código Delphi [-]
TCliente = record
  Nombre: string;
  Direccion: string;
  ...
end;

TClientes = class
private
....
public
  procedure AgregarCliente(cliente: TCliente);
  procedure BorrarCliente...
  ...
end;

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.

[tramjauer]

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.

[[Crandel]]

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.

[tramjauer]

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

[[Crandel]]

Empezado por tramjauer

Lo siento Crandel pero no te he entendido del todo bien

no hay problema.

Empezado por tramjauer

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?

Todo va dentro de la clase. Esta clase es la unica que sabe acceder a los datos de los Clientes.

Empezado por tramjauer

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?

SI

Empezado por tramjauer

+ "Luego dentro de las mismas clases debes comenzar a establecer las relaciones." ---> A que te refieres?

Por ejemplo, si tus clientes contratan Servicios, vas a tener tu clase TServivios. De alguna forma tenes que establecer la relación de que Servicios tiene contratado cada Cliente.

Empezado por tramjauer

+ "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?

Todos los componentes de la paleta Data Controls, ya tienen establecida la interfaz para acceder a los datos a traves de un DataSource, vos en este caso no lo tenes.

Empezado por tramjauer

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.

El resto de la estructura es tu trabajo , no creo que exista alguna plantilla.

[tramjauer]

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.

[adlfv]

Hola.

1.- Según me dices todos los componentes (ADOConnection, ADOQry, ADOTable, etc...) van en el formulario de la clase (ej. Tcliente), no?

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.

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

2.- Entonces si tengo muchas clases como es normal que tendré muchos ADOConnection?

No me parece lo correcto. Aunque tengas muchas tablas, la base de datos es una, con lo cual sólo debería haber (en mi opinión) una conexión a la base de datos. Lo que sí hay son vinculaciones de dicha conexión a las clases que acceden a los datos. Cuando trabajas de forma clásica pones una conexión, y tienes por ejemplo 5 tablas, pues a las 5 tablas le asignas la propiedad Connection a la conexión. Pues aquí pasa igual, tienes una conexión, pero las clases son vinculadas a ésta.

4.- Entonces si no tengo el Componente DataSource como accedo y muestro los datos en los formularios? Mediante los diferentes metodos?

En esto no te puedo ayudar, pues esto tampoco lo tengo muy claro... Me imagino que puedes hacerlo de dos formas, usando componentes DB Aware (DBEdit..) o usando componentes normales (Edits...) cómo cargarías los datos, si usas Edits normales, con métodos... Por ejemplo imagina la clase cliente... Tiene las propiedades Nombre y Apellido: String; Apellido... Pues al asignarle la propiedad en genral usas un método GetNombre: String y GetApellido: String... Luego en el método de busqueda por cliente haces algo tal que así:

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

[tramjauer]

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.