C++ y POO

[Fran]

[shephiroth]

Estoy deacuerdo en casi todo tu post, pero hay una cosa con la que no estoy deacuerdo. RTTI es util en algunos casos. Sobre que rtti viola principios teoricos de poo...cierto, los viola en las mayoria de los casos pero no en todos. Como dije en mi primer post (aunque en un tono desafortunado) hay mucha gente que se ha "mal-viciado" con su uso y ahora lo ven como una herramienta imprescindible, y ese es el error. Es util pero no imprescindible. Lo imprescindible es que disciernan entre "es una solucion" y "es la unica solucion", que no por llevarlo usando años significa que sea mejor (sino ande vamos a ir con el progreso xDD).

[\shephiroth]

Llevo diciendo todo el post q hay algunos casos en los q es casi inevitable. (Sobre todo cuando te falta tiempo para corregir una metida de pata muchas veces). Pero  PARA MI es un vicio adquirido de quien ha pasado de Estructura pura a OOP. Ya todo lo ve como un clavo. No se molesta en ver si hay algo mas que martillos.

[shephiroth]

Jaure:
Si, eduardo y jabo siguen dando clases xDD. Respecto a Algebra, llamalo casualidad, pero es la unica asignatura que no tengo el nombre del profesor xDD. Respecto a quebraderos de cabeza, despues de cobol el component pascal no es tan complicado.

Vicente:
Tienes razon, no todos los On se heredan directamente de Control. Estuve hablando de varias cosas y las lie. Con los metodos vituales On me referia a la "historia" de poner metodos virtuales vacíos...alguien comento que era mala idea eso de ir dejando metodos virtuales vacíos, y es un ejemplo muy claro de la funcionalidad y utilidad de los metodos virtuales.

Fran:
Creo q pensamos lo mismo ^_^

[zupervaca]

Este hilo es la caña jeje, sigo pensando que los dos bandos teneis razon a vuestra manera, ejemplo: si juntamos churros con merinas (o como decis algunos por aqui) el gettype es necesario, pero no por ello el usar funciones virtuales vacias esta mal, ya que como se ha dicho si el objetivo del ejercicio es mostrar en pantalla los valores se podria hacer una funcion virutal pura en la clase base que fuera pintar datos de la de clase.
He estado mirando codigo de la libreria multiplataforma que tengo ya que yo me acordaba de que en algun sitio tenia funciones virtuales vacias, es en la clase Texture de direct3d9, el motivo es que para opengl me hacia falta un par de eventos cuando se cambia la calidad de la textura, pero en direct3d9 no me hace falta, no obstante son dos funciones (eventos) que tienen algo en comun, que es algo totalmente diferente a tener una funcion virtual preguntando si un coche tiene manillar.
En definitiva creo que la base de la programacion orientada a objetos es que las clases bases desconocen a sus hijas y segun se van creando clases hijas las bases las desconocen aun mas, ademas cuando una clase base es creada y dada por finiquitada nunca mas se vuelve a tocar con lo que si se agrega un nuevo vehiculo preguntando si tiene alas al tocar la clase base estariamos rompiendo con esta filosofia (que no tiene por que ser la correcta tampoco :wink:)

Un claro ejemplo de juntar churros con merinas es meter los enemigos en la misma lista que los jugadores, si se hace esto no queda mas remedio que usar gettytpe, en cambio la forma correcta es poner una lista de enemigos y otra de jugadores. (Aunque si nos ponemos tontos podemos hacer una clase base que sepa controlar enemigos y jugadores sin gettype, es solo para un ejemplo).
Si se tiene una lista de enemigos individual se podran sacar funciones y eventos comunes para ellos y como es logico algun enemigo puede tener un evento vacio ya que puede que no tenga que hacer nada en ese caso, por ejemplo: un enemigo tiene movimiento y otro siempre esta estatico, en el evento de OnMove uno tendria codigo y el otro no, es decir, uno tiene la funcion virtual con codigo y el otro sin nada.
Ya para terminar, lo que quiero decir es que gettype se usa en casos muy raros y la mayoria de las veces por un mal plateamiento y las funciones virtuales vacias estan bien, pero siempre y cuando sean cosas comunes para las clases hijas, por lo menos es mi forma de ver la poo.

[marcode]

Estaría bien que los detractores del GetType explicasen cómo se haría para seleccionar aquellos objetos que nos interesan, por ejemplo para mostrar las imágenes o sacar una media de precios de un determinado tipo de vehiculo, o ver un listado de las características de los vehículos sin que me diga que el maletero de una moto mide cero metros.

[zupervaca]

Estaría bien que los detractores del GetType explicasen cómo se haría para seleccionar aquellos objetos que nos interesan, por ejemplo para mostrar las imágenes o sacar una media de precios de un determinado tipo de vehiculo, o ver un listado de las características de los vehículos sin que me diga que el maletero de una moto mide cero metros.

Aun mejor, veamos si eres capaz de meter en la misma tabla de la base de datos para un tipo de vehiculos los centimetros del maletero y para otros no, la solucion a este problema (si se quieren meter varios tipos de vehiculos en la misma tabla como es el caso) es un campo en el que se indican las propiedades del vehiculo.
Ademas las consultas tipo listado en la bases de datos se hacen mediante controles tipo rejilla, que tenga o no centimetros de maletero la columna de centimetros del maletero estara ahi.
Creo que has buscado un mal ejemplo :wink:

[marcode]

Puse dos por si acaso  :wink:

El otro es que quieres obtener la media del precio de todos los vehiculos de la clase coche.

Por poner otro más raro, que haya que saber que vehículos tienen que pasar la ITV este año. Aquí dependiendo de un tipo u otro varía el periodo de revisión de cada uno. Seguro que se podrían poner otros en los que no queden más narices que saber con qué estás tratando.

[Vicente]

Jaure:
Vicente:
Tienes razon, no todos los On se heredan directamente de Control. Estuve hablando de varias cosas y las lie. Con los metodos vituales On me referia a la "historia" de poner metodos virtuales vacíos...alguien comento que era mala idea eso de ir dejando metodos virtuales vacíos, y es un ejemplo muy claro de la funcionalidad y utilidad de los metodos virtuales.

Yo, yo dije que era mala idea dejar métodos virtuales vacios :p (vamos a dejarlo en que a mi no me gusta eso para evitar volver a lo de siempre). Yo no tengo nada en contra de los métodos virtuales, solo de los que están vacios. Los OnNombreEvento que comentas, NO están vacios ;)

Yo lo veo como que cuando declaras un método abstracto o en una interfaz es porque ese método es común a todas las clases hijas (una interesección) y no a solo alguna clase hija (una unión).

De todas formas, fijate como cambian las mentalidades, en Java todo método es virtual por defecto, en cambio en .NET es justo al reves, para que sea virtual lo tienes que decir tu explícitamente...

Un saludo!

Vicente

[zupervaca]

Yo en vez de por tipo lo pondria por fecha, poniendo un campo fecha que indicara cuando pasar la itv, mas que nada por si acaso hay casos especiales. No obstante estas poniendo un ejercicio en el que indicas que por "webs" hay que saber el tipo de vehiculo que se quiere mostrar, con un ejercicio en el que se haga una busqueda por tipo de vehiculo ya tienes el campo tipo de vehiculo obligado, de hay que a mi me guste poner funcionalidad extra tipo getType aunque yo no vaya a usarla, yo es que realmente no veo el problema en tener getType y no usarlo y/o tener funciones virtuales vacias :?

Editado: Pero date cuenta que realizar una busqueda por tipo no tiene nada que ver con la poo.

[shephiroth]

Buenas.

Estaría bien que los detractores del GetType explicasen cómo se haría para seleccionar aquellos objetos que nos interesan, por ejemplo para mostrar las imágenes o sacar una media de precios de un determinado tipo de vehiculo, o ver un listado de las características de los vehículos sin que me diga que el maletero de una moto mide cero metros.

Para responderte a la pregunta en violeta hay una pregunta obligatoria, para qué necesitas los datos. Si los necesitas solo para mostrarlos en pantalla, una funcion virtual de mostrar. Si quieres operar solo con una de las clases hijas podrías usar una funcion estatica y que la clase tenga por medio de una lista dinamica o algo parecido consciencia de todos los objetos de dicha clase.

"un listado de las características de los vehículos sin que me diga que el maletero de una moto mide cero metros" acaso esto no es el enunciado perfecto de "funcion virtual y que hereden las hijas"?? Aclarate ;)

Aunque me repita lo siento, pero para responderte tienes q decir exactamente para qué necesitas esos datos. La mayoria de los problemas que planteais se pueden solucionar sin tener que usar rtti.

Puse dos por si acaso  :wink:

El otro es que quieres obtener la media del precio de todos los vehiculos de la clase coche.

Por poner otro más raro, que haya que saber que vehículos tienen que pasar la ITV este año. Aquí dependiendo de un tipo u otro varía el periodo de revisión de cada uno. Seguro que se podrían poner otros en los que no queden más narices que saber con qué estás tratando.

...me lo parece a mi o estas poniendo ejemplos de una POO CLARISIMA. Funcion virtual bool necesitaItv(); y con la variable int tiempoRevisionItv. Las hijas establecen el valor de tiempoRevisionItv, al tiempo que ponen el codigo que necesita para saber si necesita o no la itv...es mas, si la clase base tiene tanto el tiempoUltimaItv como tiempoRevisionItv no necesitarias nisiquiera redefinirla en las hijas xDD.

[Jare]

Si los necesitas solo para mostrarlos en pantalla, una funcion virtual de mostrar. Si quieres operar solo con una de las clases hijas podrías usar una funcion estatica y que la clase tenga por medio de una lista dinamica o algo parecido consciencia de todos los objetos de dicha clase.

¿Las clases de la jerarquía de vehiculos necesitan saber cómo queremos (y qué necesitamos para) pintarlas en pantalla? Creamos un acomplamiento extra con nuestro sistema de pintado, que no es muy agradable de cara a la reusabilidad.

"Pasale un interfaz a la función de pintar, y así tu te lo implementas para tus funciones de pintado concretas" dirá alguno. Pero claro, para que mi interfaz pueda recibir los datos de cualquiera de las clases para usarlos como YO quiera, la función "pintar" tendrá que pasarselos de alguna forma simbólica y genérica, por ejemplo un mapa indexado por cadenas del tipo "Cilindrada" y "Consumo". No es que sea muy óptimo...

Mi implementación del interfaz de pintado tendrá que ir consultando cada elemento del mapa de datos que me da el vehículo, y hacer un... ¿switch/case o cadena de IFs? Y eso aún sería fácil si todos los datos consultables son del mismo tipo, números por ejemplo. ¿Y si algunos son floats, otros cadenas, y otros son a su vez contenedores de otros objetos, por ejemplo el campo "Cargamento"?

Eso solamente para el problema de pintarlos. Si quiero hacer una "librería de vehiculos" para que otra gente la use, tengo que preveer todos los posibles usos que la gente querrá hacer con esos vehiculos, y preparar un interfaz para cada funcionalidad. Lo siento, pero mi bola de cristal está sin pilas.

La solución de implementar una lista estática que contenga las instancias de cada clase no es que ayude mucho, ya que:

- Introduce costes extras de gestión y memoria.

- Sólo tiene sentido en clases que no tengan a su vez otras derivadas (lo que podría no ser aplicable), ya que el mismo objeto aparecería en varias listas estáticas diferentes. También hace poco viable que yo derive nuevas clases especializadas a partir de las ya existentes. Supongo que los constructores de cada clase tendrán que recibir un parámetro "bool bRegisterInStaticList" que por defecto sea true, pero que las derivadas lo pasen como false al constructor de su clase padre.

- Asume que sólo tengo una colección de vehículos sobre la que quiero iterar, o bien me obliga a asegurarme de que cada vehículo de la lista estática está en mi contenedor concreto, subiendo el coste del algoritmo de O(n) a O(n^2).

- Me obliga de igual forma a conocer todas las clases posibles, para acceder a la lista estática de cada una de ellas. Si añado nuevas clases, tengo que modificar cada algoritmo que haya implementado sobre la colección. Que es exactamente el mismo problema que tenía con los mecanismos tipo RTTI, pero con todos los problemas adicionales ya descritos.

Lo de las funciones virtuales vacías en la base no resulta muy aplicable cuando la clase base me la dan ya hecha en una librería que yo quiero extender con nuevas clases (que incluyen datos no previstos en la librería original).

En serio... de verdad os creeis que el RTTI se metió en C++ porque la mayoría de los desarrolladores son vagos o idiotas? Existen muchos problemas para los cuales RTTI es realmente la mejor solución. El que diga que esos problemas no te los encuentras en el mundo laboral, no sabe muy bien de lo que habla.

Si quieres crear una librería de objetos especializada, genérica, flexible y extensible, realmente necesitas un mecanismo de este tipo o limitarás sus posibles usos. La gente que se encontraba con este problema se inventaban su propio getType(), y al final el lenguaje incorporó una forma común de hacerlo.

[shephiroth]

Si los necesitas solo para mostrarlos en pantalla, una funcion virtual de mostrar. Si quieres operar solo con una de las clases hijas podrías usar una funcion estatica y que la clase tenga por medio de una lista dinamica o algo parecido consciencia de todos los objetos de dicha clase.

¿Las clases de la jerarquía de vehiculos necesitan saber cómo queremos (y qué necesitamos para) pintarlas en pantalla? Creamos un acomplamiento extra con nuestro sistema de pintado, que no es muy agradable de cara a la reusabilidad..

A ver, no entendi muy bien. Si tienes una funcion virtual pintar en la clase base te librara de todo rtti, pues acabara directamente en la funcion pintar de la clase que es el objeto, en la cual tiene acceso a sus variables reales y puedes codificar un metodo adaptado para ese tipo de objeto.

"Pasale un interfaz a la función de pintar, y así tu te lo implementas para tus funciones de pintado concretas" dirá alguno. Pero claro, para que mi interfaz pueda recibir los datos de cualquiera de las clases para usarlos como YO quiera, la función "pintar" tendrá que pasarselos de alguna forma simbólica y genérica, por ejemplo un mapa indexado por cadenas del tipo "Cilindrada" y "Consumo". No es que sea muy óptimo..

No se exactamente q es lo q quieres hacer. Lo unico que se me ocurre es q crees q las funciones virtuales no pueden recibir parametros, pq sino no entiendo esto. Si tu necesitas pasar como parametro la posicion de pantalla la puedes pasar directamente. Si tu problema radica en q antes de pintar tienes q utilizar funciones individuales de cada subclase, puede q el problema sea tan facil de solucionar como no agrupar peras con manzanas ;)

Mi implementación del interfaz de pintado tendrá que ir consultando cada elemento del mapa de datos que me da el vehículo, y hacer un... ¿switch/case o cadena de IFs? Y eso aún sería fácil si todos los datos consultables son del mismo tipo, números por ejemplo. ¿Y si algunos son floats, otros cadenas, y otros son a su vez contenedores de otros objetos, por ejemplo el campo "Cargamento"?

Eso solamente para el problema de pintarlos. Si quiero hacer una "librería de vehiculos" para que otra gente la use, tengo que preveer todos los posibles usos que la gente querrá hacer con esos vehiculos, y preparar un interfaz para cada funcionalidad. Lo siento, pero mi bola de cristal está sin pilas.

Aqui no coincidimos. Lo siento, pero cuando haces una librería no puedes dejar al programador al libre albedrío. Tienes q darle la funcionalidad que tu quieras, pero tienes q darla de forma eficiente no de forma eficaz. Si cuando haces la libreria le obligas al programador a estar todo el rato preguntando por el tipo puede que sea eficaz tu libreria, pues cumple con su cometido, pero eficiencia nula.

La solución de implementar una lista estática que contenga las instancias de cada clase no es que ayude mucho, ya que:

- Introduce costes extras de gestión y memoria.

gestion no se, rtti no es barato. Memoria si, pero no demasiada. 4 bytes por objeto no es mucho (en mobiles puede q si, en pc no).

- Sólo tiene sentido en clases que no tengan a su vez otras derivadas (lo que podría no ser aplicable), ya que el mismo objeto aparecería en varias listas estáticas diferentes. También hace poco viable que yo derive nuevas clases especializadas a partir de las ya existentes. Supongo que los constructores de cada clase tendrán que recibir un parámetro "bool bRegisterInStaticList" que por defecto sea true, pero que las derivadas lo pasen como false al constructor de su clase padre.

Hmmm, para clases derivadas no lo se...ademas que c y jva heredan de forma diferente. Pero partiendo de que entendiste mal lo de las listas no hago mucho caso a esto ^^;

- Asume que sólo tengo una colección de vehículos sobre la que quiero iterar, o bien me obliga a asegurarme de que cada vehículo de la lista estática está en mi contenedor concreto, subiendo el coste del algoritmo de O(n) a O(n^2).

Si, en esto tienes razon. Pero partiendo de la misma idea, pq haces una coleccion sobre la clase base, y no una de cada clase hija??? Haciendo una por hija perderias claridad en el codigo por tener q iterar por mas de una coleccion, pero ganarias el olvidarte de rtti y poo.....pero claro, es mas comodo una coleccion.

- Me obliga de igual forma a conocer todas las clases posibles, para acceder a la lista estática de cada una de ellas. Si añado nuevas clases, tengo que modificar cada algoritmo que haya implementado sobre la colección. Que es exactamente el mismo problema que tenía con los mecanismos tipo RTTI, pero con todos los problemas adicionales ya descritos.

NO, NO, NO, NO, NO Y MIL VECES NO. Aqui no me entendiste en absoluto. No me refiero en la clase base crear una lista por cada uno de sus tipos. Me referia a crear una lista estatica en cada clase HIJA. De esta forma podrias acceder directamente hija::funcion. Al crear una nueva clase no necesitarias cambiar ningun codigo existente, solo tendrías que clonar el comportamiento de la lista.

Lo de las funciones virtuales vacías en la base no resulta muy aplicable cuando la clase base me la dan ya hecha en una librería que yo quiero extender con nuevas clases (que incluyen datos no previstos en la librería original).

Aqui te doy la razon 100%.

En serio... de verdad os creeis que el RTTI se metió en C++ porque la mayoría de los desarrolladores son vagos o idiotas? Existen muchos problemas para los cuales RTTI es realmente la mejor solución. El que diga que esos problemas no te los encuentras en el mundo laboral, no sabe muy bien de lo que habla.

No se cuantas veces lo habre dicho ya, YAH CASOS EN LOS Q RTTI ES UTIL, otras veces NOOOOOOOOOOOOO.

Si quieres crear una librería de objetos especializada, genérica, flexible y extensible, realmente necesitas un mecanismo de este tipo o limitarás sus posibles usos. La gente que se encontraba con este problema se inventaban su propio getType(), y al final el lenguaje incorporó una forma común de hacerlo.

Aqui tampoco comparto tu opinion. Si una libreria esta limitada una de dos:
1- No se le quiso dar mas funcionalidad.
2- No se le supo dar mas funcionalidad.

Para mi q ninguna de las dos depende ni de poo ni de rtti.....

SALUDOS

[Jare]

A ver, no entendi muy bien..

Si piensas que YO hago una librería de clases para vehículos, y que tú quieres usarla en tu aplicación (de cuyo pintado y necesidades yo no sé ni puedo saber nada), entonces verás a qué me refiero.

NO, NO, NO, NO, NO Y MIL VECES NO. Aqui no me entendiste en absoluto. No me refiero en la clase base crear una lista por cada uno de sus tipos. Me referia a crear una lista estatica en cada clase HIJA. De esta forma podrias acceder directamente hija::funcion. Al crear una nueva clase no necesitarias cambiar ningun codigo existente, solo tendrías que clonar el comportamiento de la lista.

¿Y quién es el que accede a cada una de esas listas? Recuerda la idea de que la librería de vehículos no puede ni debe saber nada sobre lo el uso concreto que la aplicación quiere hacer de ella.

[Fran]

Puse dos por si acaso  :wink:

El otro es que quieres obtener la media del precio de todos los vehiculos de la clase coche.

Por poner otro más raro, que haya que saber que vehículos tienen que pasar la ITV este año. Aquí dependiendo de un tipo u otro varía el periodo de revisión de cada uno. Seguro que se podrían poner otros en los que no queden más narices que saber con qué estás tratando.

Joder, este si q es de huevo

Este es muy facil. Implementas el método virtual en la clase vehiculo getPlazoRevision lo pones por ejmpllo por defecto a 4 si no quieres redefinirlo en los coches y en las motos y si no lo pones a 0 y lo redefines hay tb y en el resto de vehiculos (ej. camiones) lo pones a lo q sea p.e. 1. Despues en la clase base pones un método

clase base (lo pongo todo en pseudocodigo por no particularizar en ningun lenguaje xq esto es valido para Java,Delphi,C++,SmallTalk....)

Vehiculo{
.....
 virtual getPlazoRevision(){result=4}
 boolean getMeTocaLaRevision (dtFecha del tipo DateTime)
.....
}

(cocheparticular y moto no los redefino xq ya me valen  o si no, el de vehiculo lo pongo a 0 y estos dos a 4)

Camion{
 override getPlazoRevision(){result=1}//o el tiempo q sea
}

Taxi{
 override getPlazoRevision(){result=3}//o el tiempo q sea
}

Autobus{
 override getPlazoRevision(){result=2}//o el tiempo q sea
}


en el vehiculo

boolean getMeTocaLaRevision (dtFecha del tipo DateTime)
{
 result= pasarAAnyos(dtFecha-getFechaAlta())>=getPlazoRevision()
}

y ya está.  Sin getType ni RTTI ni nada

Ese es un ejemplo desafortunado para la RTTI xq muestra claramente donde es util la OOP, virtuales, herencia, etc... Es de libro para hacerlo con funciones virtuales. Si haces esto con getType , no digo q esté mal, pero programas estructuradamente sin OOP y sin nada. Si mañana te acuerdas q se te han olvidado las bicicletas con RTTI tendrias q modificar la clase base (un case, antiOOP) si lo haces con virtuales, si le has puesto en la base tiempoderevision=0 no tendiras q hacer nada, si le has puesto 4, declararias esto y ya esta

Bicicleta{
 override getPlazoRevision(){result=0}//o el tiempo q sea
}

No tocas la clase base->no hay efectos colaterales no previstos. Solo tienes q hacer overrride de un método en la clase q estás creando, y lo mejor. No obligas a nadie a conocer el resto de la jerarquia para meter una funcionalidad nueva.

[marcode]

"un listado de las características de los vehículos sin que me diga que el maletero de una moto mide cero metros" acaso esto no es el enunciado perfecto de "funcion virtual y que hereden las hijas"?? Aclarate :wink:

Aclárame tú cómo hacerlo con una función virtual, por ejemplo: Necesito averiguar de la lista de vehículos en un momento dado, cuál es el que tiene el maletero más pequeño.


El problema de obtener el precio medio de los coches todavía creo que no ha sido resuelto sin usar el GetType, Aquí va:

Código [Seleccionar] Expand


int precioSuma = 0; int n = 0;

for (int i=0;i<100;i++)
{
if (Vehiculo[i]->GetType() == COCHE) {
precioSuma + = Vehiculo[i]->GetPrice();
n++;
}

}

int precioMedioCoches = precioSuma/n;


Estoy usando el "Type" como una propiedad más del objeto,  al fin y al cabo también puedes tener GetModel, GetCategory, GetClass, etc. No veo que hay de malo. Si además me interesan sólo los vehículos de 5 puertas haría:

Código [Seleccionar] Expand


if (Vehiculo[i]->GetType() == COCHE &&
Vehiculo[i]->GetPuertas() == CINCO_PUERTAS) { ....


Y en cuanto a los otros ejemplos en el que se da la solución de ir añadiendo más y más funciones virtuales (como comenta Fran),  ¿que pasa cuando no se puede modificar la clase base por la razón que sea?, por ejemplo porque solo tengas el C.Objeto, o porque el diseñador no le apetece que le meta mano todo programador que quiera resolver su problema puntual.

¿Y cuando se necesita iterar una cantidad exagerada de objetos como pudieran ser partículas por ejemplo para calcular la fuerza de gravedad que ejercen unas sobre otras?, olvídate de usar funciones virtuales.

De todos modos no discutiré si la POO auténtica es de una forma u otra, (no estudié lo suficiente), solo discuto si realmente es eficaz seguirla estrictamente.

[Fran]

Y en cuanto a los otros ejemplos en el que se da la solución de ir añadiendo más y más funciones virtuales (como comenta Fran),  ¿que pasa cuando no se puede modificar la clase base por la razón que sea?, por ejemplo porque solo tengas el C.Objeto, o porque el diseñador no le apetece que le meta mano todo programador que quiera resolver su problema puntual.

¿Y cuando se necesita iterar una cantidad exagerada de objetos como pudieran ser partículas por ejemplo para calcular la fuerza de gravedad que ejercen unas sobre otras?, olvídate de usar funciones virtuales.

¿?  Quizás no me he explicado bien. Es q con esa solución (con la q yo he dado) no necesitas tocar para nada la clase base . Nadie tiene q tocarla para resolver el programa añadas lo q añadas. Ni siquiera tienes q saber como funciona. Ahi está lo grande. Y en el caso de particulas, mejor, no tienes que saber de qué tipo es ni nada de nada. Simplemente por ejemplo redefinir su método masa() o carga() en funcion del tipo de partícula que sea y ya está. Nada más.