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

tramjauer · #1 02-09-2005

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 · #2 02-09-2005

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 · #3 02-09-2005

Cita:

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 · #4 02-09-2005

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] · #5 03-09-2005

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 · #6 04-09-2005

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.

tramjauer · #7 04-09-2005

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 · #8 04-09-2005

Hola,

Cita:

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.

Cita:

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.

Cita:

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 · #9 04-09-2005

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] · #10 05-09-2005

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:

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 · #11 05-09-2005

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] · #12 05-09-2005

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.