Abstracción de aplicación por departamentos

[adlfv]

Hola a todos.

Estoy haciendo un programa y he hecho una jerarquía de departamentos, en los cuales quiero encapsular todas las funciones de cada departamento como pueden ser acciones, operaciones, reportes...

La idea es que cada departamento esté en un .bpl, y que al eliminar el .bpl de ese departamento, no pueda realizar las funciones que realiza ese departamento (pero sí pueda seguir ejecutando la aplicación, salvo que sea un departamento muy vital).

Si los paquetes son vinculados de forma estatica, no puedo ejecutar la aplicación al eliminar alguno de ellos, pero si son vinculados (cargados) de forma dinámica, sí puedo hacer eso pero tengo que apañarmelas para hacer las llamadas a las rutinas, acceder a los objetos, y todo eso.

El problema que veo es cómo desactivar o borrar un departamento, y se me ocurren dos soluciones:

1.- Si tengo un "flag" de activado/desactivado, tengo el problema que por ingeniería inversa me pueden activar departamentos que no deseo que activen, por ejemplo usar departamentos por los cuales no han pagado, pero me facilita mucho la vinculación con el programa, pues puedo usar vinculamiento estatico.

2.- Si uso el metodo de "borrar" los departamentos que no uso, tengo el problema que tengo que armar todo para poder usar los objetos dentro de los paquetes, llamar a las rutinas, activar y desactivar menus y todo eso en funcion de si existe el archivo .bpl o no. Aparte tengo el problema que no sé cómo "engañar" al compilador, pues al compilar se supone que los paquetes siempre van a estar ahí (porque necesito establecer las llamadas a dicho paquete) pero al ejecutar no siempre estará ahí.

Me inclino más por la segunda pues me parece que es más "moldeable" y más independiente, pero no sé muy bien cómo resolver ese inconveniente. He pensado en hacer un interfaz común entre los objetos del paquete (departamento) y el programa mediante una clase abstracta que no haga absolutamente nada (pero que sí pueda instanciar, aunque no tenga sentido) para "engañar" al compilador, y que si el paquete existe se sobrecarguen los métodos o algo así, y se le de la funcionalidad al paquete.

Alguna idea? Alguna sugerencia? Me expliqué bien?

Muchas gracias de antemano.

Un cordial saludo

[roman]

Empezado por adlfv

He pensado en hacer un interfaz común entre los objetos del paquete (departamento) y el programa mediante una clase abstracta que no haga absolutamente nada (pero que sí pueda instanciar, aunque no tenga sentido) para "engañar" al compilador, y que si el paquete existe se sobrecarguen los métodos o algo así, y se le de la funcionalidad al paquete.

A mi entender éste es el camino a seguir. Me da la impresión de que temes que esto sea una chapuza, pero no se trata de estar engañando al compilador, sino aprovechando la potencia del polimorfismo.

Pero de esto ya habíamos hablado anteriormente ¿no?

// Saludos

[adlfv]

Hola Roman.

Primero que nada, gracias por contestar.

Efectivamente lo hablamos con anterioridad, pero todavía me queda ese sabor de boca de "estoy haciendo algo raro, y es posible que haya una forma mejor de hacerlo" (por favor no lo tomes a mal, no es una ofensa es simplemente la inexperiencia de hacer algo nuevo), y por eso preguntaba...

Lo voy a intentar a ver que tal.

Por cierto, los interfaces no me sirven en esto? Qué utilidad puede tener un interfaz en una clase cuyos métodos son todos abstractos?

Otra cosa, al tener métodos abstractos la clase, no me dará fallo al crear un objeto de esa clase?

Muchas gracias de nuevo.

Un cordial saludo.

Como podrás ver, me quedé varado con el programa un buen tiempo... Tuve un problema con un Access Violation que me volvió loco por más de un mes y no conseguía el fallo... hasta que al final lo conseguí, pero cómo me costó! jejeje. Desgraciadamente perdí mucho tiempo