Asias, chaval...
pkdor <pkdor@...> wrote:
Bueno, las clases hijas pueden tener nuevos metodos si lo deseas, sólo que
no vas a poder usarlos sin saber previamente el tipo concreto :D.
Esos nuevos métodos.....¿son cada uno de su padre y de su madre? Por que
si me dices que las clases hijas además de los metodos del padre van a
tener en algunos casos el método HazAlgo(), entonces podrias combinar la
fabrica abstraca con Interfaces:
/* pseudocodigo */
ClasePadre chija = ClasePadre.crearClaseHija(XXXXX) ;
chija.metododelpadre();
if (chija implements IHacerAlgo){
((IHacerAlgo)chija).HazAlgo( );
}
Y si la respuesta es que en las clases hijas puede haber cualquier método
con definición desconocida a priori, entonces veo dificil que puedas hacer
nada generico.
Saludos!
P.D: aprovecho para recomendar http://www.usaelputogoogle.com/ (mejor con
firefox)
> Desafortunadamente, la premisa de que las clases hijas
> no añadan nuevos no se cumple para todas las
> subclases...
>
> --- pkdor <pkdor@arrakis.es > wrote:
>
>> Buenas!
>>
>> No he contestado antes porque el mensaje estaba en
>> la carpeta de spam.
>>
>> Si las clases hijas (concreatas) se limitan a
>> implementar los métodos
>> abstractos de la clase padre (es decir, no añaden
>> nuevos métodos), no
>> necesitas conocer el tipo de la clase concreta.
>> Podrías usar el patrón
>> fábrica abstracta. Ejemplorrrr:
>>
>> ClasePadre chija = ClasePadre.crearClaseHija(XXXXX) ;
>> chija.metodo
>>
>> Dode ClasePadre.crearClaseHija es un metodo
>> estatico, y el parametro que
>> recibe es "algo" que te permita decidir que clase
>> hija crear. El metodo
>> getFactory podria ser un if anidado, o si lo quieres
>> mas generico, podria
>> acceder a un fichero de configuracion donde
>> obtendria en tiempo de
>> ejecucion la clase concreta a instanciar para el
>> valor de XXXXX dado.
>>
>> No se si esto es lo que buscas o no. Yo uso este
>> sistema en multiples sitios.
>>
>> Saludos!
>>
>>
>> > Hola gente,
>> >
>> > Pues aunque no me prodigo mucho escribiendo al
>> foro
>> > ultimamente, pero ahí sigo leyendo (casi) todo lo
>> que
>> > escribís...
>> >
>> > Bueno, ando con una duda de análisis-diseño OO
>> sobre
>> > J2SE 1.4.2 (si ya se que anda la 1.5.0 desde hace
>> > algún tiempo, y que la 1.6.0 está ya a la vuelta
>> de la
>> > esquina..pero eso no viene al cuento) a ver de las
>> > mentes pensantes que sepan más que yo quien me
>> puede
>> > echar una mano. La situación es como sigue:
>> >
>> > Tengo una unidad de algo que declaro como
>> abstracto y
>> > que encapsula todo lo común a los diferentes tipos
>> de
>> > unidades concretas que puedo encontrar. A día de
>> hoy
>> > conozco en torno a unas 20-25 tipos de unidad
>> > concretas, pero no estoy seguro que en el futuro
>> > puedan aparecer otras, así que quiero dejar la
>> puerta
>> > abierta. Hasta aquí sin problemas ya que para
>> crear
>> > nuevas, simplemente heredo una nueva subclase
>> concreta
>> > de mi superclase Unidad.
>> >
>> > El punto es que para averiguar el subtipo concreto
>> no
>> > me quedaría de otra que usar el getClass(). No soy
>> muy
>> > amigo de usar ese método por ciertas razones, así
>> que
>> > empiezo a pensar y se me ocurre que podría tener
>> un
>> > campo tipoUnidad, de tipo int y tener una serie de
>> > constantes (final) que identificasen de forma
>> concreta
>> > a las subclases:
>> >
>> > Ej:
>> > public static final int UNIDAD_CONCRETA_A=1;
>> > public static final int UNIDAD_CONCRETA_B=2;
>> > ...
>> >
>> > Y aquí viene el problema; Si estas constantes las
>> > pongo en la superclase no me quedará de otra que
>> > violar el encapsulamiento si eventualmente
>> aparecen
>> > nuevas clases concretas. Pero si decido bajarlo a
>> las
>> > subclases y que cada subclase defina su constante
>> > resulta que no puedo asegurar que cada subclase
>> elija
>> > un valor distinto a las otras ya que las subclases
>> no
>> > necesariamente se conocen entre si...amén de que
>> no
>> > tendría todas las constantes en la misma clase y
>> eso
>> > supone un problema a la hora de usarlas...
>> >
>> > A alguien se le ocurre algo más, que no sea el ya
>> > mencionado uso de getClass()? Algún patrón de
>> diseño
>> > por ahí que haga esto?
>> >
>> > En fin, cualquier sugerencia será
>> bienvenida...sino,
>> > me temo que tenré que usar el getClass() "manque"
>> me
>> > pese...
>> >
>> > Saludos,
>> >
>> > Felipe
>> >
>> >
>> >
>> >
>>
> _____________________ _________ _________ _________ _________ _
>> > Any questions? Get answers on any topic at
>> www.Answers.yahoo.com. Try it
>> > now.
>> >
>>
>>
>
>
>
>
> _____________________ _________ _________ _________ _________ _
> Yahoo! Music Unlimited
> Access over 1 million songs.
> http://music.yahoo.com/ unlimited
>
Any questions? Get answers on any topic at Yahoo! Answers. Try it now.