Desafortunadamente, la premisa de que las clases hijas
no añadan nuevos no se cumple para todas las
subclases...

--- pkdor <pkdor@...> 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