FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Buscar | Temas de Hoy | Marcar Foros Como Leídos |
|
Herramientas | Buscar en Tema | Desplegado |
#1
|
|||
|
|||
Se puede hacer esto en POO?
Hola a todos.
Tengo un problema de POO y no sé si es posible hacer lo que quiero hacer, pero me imagino que sí, el problema es que no sé cómo... A ver si alguien me puede echar una mano. Tengo una clase TBaseHabitacion, de la cual heredan otras clases qeu representan habitaciones en un estado concreto; por ahora la jerarquía es más o menos así... TBaseHabitacion - THabOcupada (abstracta) - THabOcupadaCliente (abstracta) - THabRenovada - THabWarning - THabVencida - THabOcupadaPersonal (abstracta) - THabLimpieza - THabMantenimiento - THabNoOcupada (abstracta) - THabReserva - THabDisponible La idea es en el objeto Habitaciones (que es la lista de las habitaciones) poder hacer algo como esto (similar a AsInteger, AsBoolean de TField): A la hora de implementar el método "AsOcupadaCliente: THabOcupadaCliente", me dí cuenta que no se podía incluir en TBaseHabitación porque el compilador aún no sabe nada de esa clase THabOcupadaCliente debido a que se implementa después, y hereda de TBaseHabitacion... Existe alguna forma de implementar estos métodos en TBaseHabitación? Esto lo resolví haciendo como un "wrapper" de TBaseHabitacion al final del todo... Hasta aquí todo claro... Ahora viene "el dilema" Después me di cuenta que al analizar cada habitación para saber su estado, tendría que estar destruyendo y volviendo a crear y buscar los tipos de habitaciones cada vez (lo cual es muy ineficiente) pues la idea es crear la habitación una sola vez, al igual que obtener el tipo de la habitación (pues se supone que no cambiarán)... Entonces pensé en separar lo que es la información "basica" de una habitación (Id, estado...) de la información "especifica" de esa habitación, incluyendola como una clase, de forma que al analizar cada habitación sólo tenga que crear/destruir la información específica de la habitación. Pero esto no parece muy compatible con el planteamiento inicial de la jerarquía de las habitaciones, porque la información específica la incluyo como una propiedad de TBaseHabitación, pero no puedo "redefinir" dicha propiedad especializando su tipo en clases descendientes, es decir, Info en TBaseHabitación es de tipo TBaseInfo, pero Info en THabOcupadaCliente debería ser de tipo TInfoOcupadaCliente... Al ver esto... lo primero que se me vino a la cabeza fue... Estoy "reduciendo el problema al mismo problema "... Y dije... bueno, hago lo mismo para la info... es decir... Pero al ver la jerarquía de la información en función del estado, me pasa lo mismo, tendría que hacer otro wrapper. El problema es que, no veo forma de que el siguiente código funcione correctamente, porque si Info es de tipo TBaseInfo, me da error al intentar acceder a AsOcupadaCliente, pues está implementado en el wrapper, pero si es de tipo TWrapperInfo, entonces me da error al hacer el create... Entonces qué hago? Qué estoy haciendo mal? Se puede simplificar toda esa estructura y esa jerarquía? Le agradezco enormemente a cualquiera que se haya tomado la molestia de leer el mensaje, porque para entender este toston, no es muy facil que digamos. Muchas gracias a todos, agradezco sus comentarios. Un cordial saludo PD: Incluyo los interfaces de las clases citadas, por si alguien tiene dudas o quiere ver el código. Última edición por dec fecha: 22-09-2005 a las 07:05:33. Razón: ¡¡Encerrad el código fuente entre las etiquetas [DELPHI] ... [/DELPHI]!! |
#2
|
||||
|
||||
Cita:
¿Es simplemente eso o no te entedí? Por otro lado, te parece clasificar tanto las habitaciones en lugar de que cuando una este ocupada o no este sea un mero dato de una misma clase?
__________________
delphi.com.ar Dedique el tiempo suficiente para formular su pregunta si pretende que alguien dedique su tiempo en contestarla. Última edición por delphi.com.ar fecha: 21-09-2005 a las 17:21:59. |
#3
|
||||
|
||||
Sinceramente, me parece un abuso del uso de la herencia, Es una jerquia muy densa, donde cada subclase aporta poco. Estas armando una jerarquia donde deberia ir un manejo de estados y poliformismo.
Es cierto que es mas simple manejar clases sin estado (por ejemplo, en vez de tener una clase que lea y escriba archivos, tener un LectorArchivo y un EscribeArchivo). Pienso que deberias dibujar (asi sea a lapiz) las clases y sus estados. Reduce la jerarquia y maneja una propiedad con el estado. En lo poco que se ve, me parece que solo existen 2 clases practicas aqui: THabOcupada THabNoOcupada y el resto por poliformismo. Luego un administrador de Habitaciones (que se encarge de cambiar de una ocupada a una desocupada, etc...) Para evitar borrar y crear los objetos sin necesidad, puedes sobreescribir el metodo Assign (debes derivar de TPersistent) En fin, echale cabeza al diseño. Te daras cuenta cuando quedo bien hecho, porque veras que no hay que "hackealo" pa que funcione
__________________
El malabarista. |
#4
|
||||
|
||||
Como dijo mamcx, creo que es un abuso de jerarquía, pero veo las clases:
* THabitacion. * TCliente. La clase es THabitacion y el resto son estados de él IsOcupadaCliente es una propiedad que verifica el Estado y devuelve verdadero o falso. TCliente es otra clase que tiene los datos de cada cliente. Luego tendrias que tener una lista de clientes. y cuando se ocupa una habitación lo que haces es asiganarle el cliente a la habitación, de manera de hacer, por ejemplo: Habitacion.Cliente.Nombre De esta forma tambien te va a resultar mucho más facil en un futuro si queres almacenar los datos en una base de datos, en archivo de texto o lo que sea.
__________________
[Crandel] |
#5
|
|||
|
|||
Ampliando un poco lo dicho por Crandel:
La clase THabitación puede tener una propiedad Estado, tal que:
Saludos... |
#6
|
|||
|
|||
Muchas gracias a todos por contestar...
Lo que pasa es que estoy "reinventando la rueda"... Llevo un tiempo ya con este programa, y lo había hecho todo "a lo bestia" prescindiendo de la POO, empleando basicamente un vector y un tipo enumerado... Ahora estoy rehaciendo todas las tripas del programa para hacerlo lo mejor posible para posibles expansiones, personalizaciones y mejoras en el futuro... Y bueno, con la mentalidad "hibrida" de antes y ahora, a veces lo obvio no se vé tan claro jeje . Es horriiiiiiiible la labor de re-ingeniería... Lo ideal hubiera haberlo hecho bien desde un principio, prácticamente lo que he hecho ha sido tiempo perdido... Lo único que sí he podido aprovechar es el diseño de la base de datos... El resto, mucho lo he tenido que retocar, o rehacer... Espero que el resultado final sea ampliamente "escalable" y flexible... Muchas gracias de nuevo a todos. Un cordial saludo... |
#7
|
||||
|
||||
Cita:
__________________
delphi.com.ar Dedique el tiempo suficiente para formular su pregunta si pretende que alguien dedique su tiempo en contestarla. |
#8
|
|||
|
|||
Sí claro, a mi me gusta...
Me refería a que resulta doloroso ver que "lo que funcionaba" ya no funciona al estar en proceso de reconstrucción... Eso sí es horrible... Pero va dando gusto cuando empieza a funcionar de nuevo . |
#9
|
||||
|
||||
Resp
Si necesitas algun metodo que no existe en un aclase y es eredada simplemete has un casting pero si solo quieres que lo smetodos no sean implemtados por la supercalse(clase base) y se implmemnten el los heredados usa metodos abstractos el cla clase base o virtuale si levan algun codigo en comun y le haces un overrride en la caklse que lo heredan.
__________________
Todo se puede, que no exista la tecnología aun, es otra cosa. |
Herramientas | Buscar en Tema |
Desplegado | |
|
|
|