Prog OO , Clases de Negocio y division en capas
 

Hola a todos:
Hace bastante que programo en delphi pero hace poco intento desarrollar las aplicaciones con la Prog OO que hasta ahora venia siendo teorica. Para eso he leido UML, que como conocerán ayuda a delimitar y apreciar el sistema desde varios puntos de vista gracias a los diagramas que proporciona. Pero basicamente se llega a un diagrama de clases divido en tres capaz o niveles, de Acceso a Datos, De Reglas de Negocio y de Interfaz con el usuario. Ademas de esto he leido como algunos desarrollan las aplicaciones con la prog a Objetos especificamente en Delphi. y ESTE ES EL PUNTO al que queria llegar. ¿ Cual es la forma mas apropiada para implementar el conjunto de clases resultantes de alguna metodologia en delphi.?

Mi pregunta no apunta a que me expliquen como se crean clases, conceptos de polimorfismo , herencia etc. sino cuales son las clases que principalmente se crean en una aplicacion sencilla conformando, una estructura que posea la potencia de la programacion OO. Cuales son las propiedades y metodos de esas clases y como se comunican con las clases de otros niveles.

Porque me cuestiono esto?. porque he leido p.e. que algunos recomiendan validar las reglas de negocio en eventos del registro (afterpost, beforepost), y que las clases de acceso a datos se
deben definir en el datamodule. Hasta aca no hay nada raro, el punto que le encuentro conflictivo es
*como se pasan parametros Los objetos?, es decir el conjunto de registros. Lo hacen por medio de un dataset?. Si es asi .. como lo hacen?
*el resultado a un metodo como "leertabla" deberia pasar el dataset por valor , para que cada instancia del objeto sea independiente de la otra.. Como podria yo lograr esto?

Si no he sido claro con mis dudas, les pido que por favor me pregunten. Tengan en cuenta tambien que es mi primer incursion en la prog OO y les agradeceria muchisimo que me dijeran

cual les parece la forma mas optima de realizarlo.. muchas gracias

Fabian Bobadilla
Corrientes - Argentina

Hola,

Lo que preguntas, más que para una respuesta de un foro, daría para un libro entero. Es bastante complejo explicar cómo adaptar la teoría OOP a Delphi y, además no existe El Método para hacerlo. Aunque he leído y probado muchas maneras de hacerlo, la que, en mi opinión, es más versátil y productiva se acerca mucho a la que se expone en el último número de la revista Sintesis.
Si no conoces esta publicación, te diré que es una revista gratuita, en español y on-line que sale bimensualmente y trata sobre los entornos de desarrollo de Borland, especiamente Delphi. Si quieres bajártela tienes que ir a http://www.grupoalbor.com y seguir las instrucciones de descarga.

Solo quiero aclarar que OOP no es equivalente a MultiTier...

En delphi, aunque programes un sencillo formulario, estas haciendo uso, quizas sin saberlo, de una compleja y muy bien diseñada jerarquia de objetos, herencia, polimorfismo, etc, que al final de cuentas es la OOP, no???

Hasta luego.

;)

Hola

>Solo quiero aclarar que OOP no es equivalente a MultiTier...

Si es cierto.. pero nadie dijo lo contrario.. Es mas en todo caso si solo utilizas los objetos de delphi, seria mas bien. Una aplicacion basada en objetos y no Orientada a objetos.. (o no?) .

Si revisaron el articulo de la revista sintesis como lo recomienda "marto", dicho sea de paso.. muchas gracias.. Ahi se desarrolla un ejemplillo , que aunque no responde a todas las preguntas.. orienta y sirve para dar los primeros pasos..
Les comento para que se den una idea de adonde apunté cuando postee la pregunta...

Saludos desde Corrientes, Argentina

Hola

>Solo quiero aclarar que OOP no es equivalente a MultiTier...

Si es cierto.. pero nadie dijo lo contrario.. Es mas en todo caso si solo utilizas los objetos de delphi, seria mas bien. Una aplicacion basada en objetos y no Orientada a objetos.. (o no?) .

Si revisaron el articulo de la revista sintesis como lo recomienda "marto", dicho sea de paso.. muchas gracias.. Ahi se desarrolla un ejemplillo , que aunque no responde a todas las preguntas.. orienta y sirve para dar los primeros pasos..
Les comento para que se den una idea de adonde apunté cuando postee la pregunta...

Saludos desde Corrientes, Argentina

Hola,

hace tiempo, en los foros antiguos, tratamos el tema que planteas desde otro punto de vista.

Te pongo el enlace al hilo porque hay alguna referencia que tal vez te interese también ...

http://clubdelphi.com/foros/archivo/...1fb57f6eb09fa5

Saludos.

¡Buen día a todos!

La programación orientada a objetos en Delphi puede ser implementada a diferentes niveles.

Podríamos decir que el más básico de ellos es cuando se crea una aplicación con clases de objeto componente ya definidas, donde la manipulación visual del diseño se ejerce directamente sobre objetos instanciados en tiempo de diseño y a instanciarse en tiempo de ejecución. Es el caso de una aplicación básica que contiene una o varias formas (componente TForm) conteniendo componentes de diversos tipos (descendientes de TComponent).

Por otra parte pueden definirse nuevas clases de objeto (componentes y no componentes) a partir de clases ya existentes. Esto requiere de conocimientos y esfuerzos de mayor profundidad, pero vale la pena invertir en ellos.

La creación de nuevas clases de objetos debe ir junto con la creación de otros recursos de programación, es decir, es todo un conjunto que abarca clases de objetos, funciones y otras estructuras auxiliares de código e información.

Estos recursos deben ser divididos en dos partes: la biblioteca de recursos estándares generales y la biblioteca de recursos propios del proyecto.

Por ejemplo, si para un proyecto de sistema de control escolar se crea una clase TTablaAlumnos derivada de TTable, esta nueva clase de componente pertenece a la biblioteca de recursos del proyecto. Pero si se crea una clase TTablaMejorada derivada de TTable, con características estándares que pueden ser aprovechadas en más de un proyecto (y que no son particulares de ninguno), entonces esta nueva clase debe pertenecer a una biblioteca de recursos estándares, común a varios proyectos existentes o por existir.

Sin embargo, los recursos de bibliotecas estándares requieren ser desarrollados pensando en más diversas necesidades y posibilidades de falla (generalmente necesitan más validaciones), que los recursos de la biblioteca particular de un proyecto, donde las condiciones alcanzables de alguna manera ya están previstas.

La programación orientada a objetos resuelve problemas de complejidad de datos y procesos, pero no siempre es mejor que la programación estructurada tradicional. De ahí que Delphi permita al programador decidir que tan orientado a objetos trabajar.

:)

Algo que me gustaría recalcar es la posiblidad que tiene Delphi de implementar plantillas de formas. Crear dos formas diferentes con elementos comunes repetidos, es como crear dos funciones diferentes con código común repetido.

Generalmente, cuando se crea una función que tiene un grupo de sentencias igual al de otra función, lo recomendable es colocar las sentencias que tienen en común en una tercera función, evitando la repetitividad de código para evitar los problemas comunes que de ello derivan (mayor tamaño de código, mayor esfuerzo y tiempo para actualización, menor seguridad).

Delphi permite aplicar esto mismo a las formas (¡y con verdadera programación orientada a objetos! :)). Por ejemplo, uno puede crear una plantilla de forma para operaciones de venta, y de ella derivar una forma para captura de cotizaciones y otra para captura de pedidos. Todos los elmentos comunes (componentes, valores de propiedades y código de manejadores de evento) se colocan en la forma y unidad de la plantilla (TPlanOperVent), dejando los demás elementos en las formas derivadas (TFormCoti y TFormPedi).

Esto da un mayor control sobre el diseño y depuración de la aplicación, hace más legible el código, y centraliza los elmentos comunes en en la plantilla, de tal forma que al hacer un cambio ahí, éste se aplica automáticamente en las formas derivadas.

Cabe mencionar que en las plantillas se pueden crear métodos virtuales que pueden ser redefinidos (Override) en las clases derivadas, también pueden agregarse nuevas propiedades y redefinirse el constructor virtual Create. No olvidar tampoco, que como se trata de verdadera programación orientada a objetos, es posible tomar una plantilla y derivar otra plantilla de ella, y así sucesivamente, hasta definir la clase de forma final que observa el usuario.

Espero esto sea de utilidad, seguimos en contacto.

Al González :).