siendo puristas, se trata de un fabrica simplificado. Mas info, con
ejemplos y dibujitos en:

http://www.microsoft.com/spanish/msdn/comunidad/mtj.net/voices/MTJ_3624.asp

> Eso de combinar la Fabrica Abstracta con el uso de interfaces suena mas
> que razonable. Como bien dices aun tendre que usar el getClass() previo al
> uso de los mètodos especificos de las subclases cuando sea necesario, pero
> ya se habrá reducido bastante... Vi proba a ve que sale...
>
> 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@...> 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.