Cita:
Iniciado por venkman 
Bueno, lo cierto es que creo que no es problema del lenguaje, yo tampoco en Java optaría por ese tipo de solución. Te comento por qué digo esto.
En primer lugar, me pregunto hasta qué punto lo que necesitas son clases específicas o tan sólo es un contenedor genérico de propiedades, digamos una HashTable que contiene tan sólo unos cuantos valores. Por tu descripción, no veo que vaya a contener ningún tipo de lógica.
Aún así, admitamos que pueda ser una clase particular (llamémosla EstadoVisualizacion, p.ej.). Sin embargo, incluso así, no veo que realmente tenga esa clase interna que acceder a la clase SistemaSolar. ¿Por qué para recuperar el color de fondo debería EstadoVisualizacion acceder a SistemaSolar? ¿No es precisamente el objetivo de EstadoVisualizacion guardar el color de fondo?
Más aún, ¿por qué la necesidad de que sea interna a SistemaSolar si quien dices que va a tener que acceder a ella son los planetas? De hecho, ¿por qué hacerla una clase interna?
No sé, como decía creo que no se trata de un tema de lenguaje, sino más bien que el diseño de la aplicación es lo que no termina de encajar. Y ojo, que no digo que esté mal, sólo que por lo que has descrito yo no lo veo. Si quieres podrías describirlo de forma un poco más concreta y lo hablamos. (Sólo si quieres, eh)
¡Claro! Acepto cualquier sugerencia, siempre que haya alguien dispuesto a escucharme
. Te lo describiré un poco más en detalle.
No sé si alguna vez has usado pygame, pero supondré que no. Es un framework para desarrollo de aplicaciones multimedia (básicamente, gráficos 2D, sonido y manejo de eventos) en Python, bastante orientado al desarrollo de videojuegos en concreto (y muy recomendable, creo yo).
Hay una clase Sprite pensada para ser extendida, y es base de mis clases Astro y AstroOrbitante (el Sol y los planetas, vaya), donde se define la construcción gráfica de un astro y los movimientos que describe en la pantalla, y hay varias clases para agrupar y manejar con facilidad sprites, una de ellas (la más simple) Group, que es heredada por mi SistemaSolar, el cual maneja cómo se añaden planetas, cuando se actualiza su estado y cuándo se redibujan.
Como en el sistema solar hay cosas muy grandes y muy pequeñas (pensaba poner incluso satélites), mi idea es que se pueda hacer zoom y mover la pantalla (¡mientras que los planetas se mueven, y todo!), así como acelerar o frenar el paso del tiempo para apreciar los movimientos (días/frame, o algo así).
De este modo, todos los planetitas tienen que moverse de acuerdo a una velocidad del tiempo y deben aparecer con un tamaño y en una posición adecuados al zoom actual, y deben borrarse (si has programado algo de gráficos, sabrás que los movimientos pueden verse básicamente como borrar y replicar en otro sitio) con el mismo color de fondo (el negro del espacio, por ejemplo).
De este modo, quizás con algún detalle más que me olvide, hay varios parámetros comunes para todos los planetas; además, tengo en cuenta que un Astro o un AstroOrbitante sólo valen para algo si se los pongo a un sistema solar.
Dicho esto (espero que haya quedado al menos medio claro), quizás por mi formación en programación o quizás por que fue lo primero que se me ocurrió (en realidad, lo segundo o lo tercero), decidí hacer las clases Astro y AstroOrbitante anidadas en SistemaSolar, de modo que un sistema solar contiene astros, es decir, como una manera más "natural" (para mí) de estructurarlo.
Sí que pensé en soluciones que no implicaran esto. Lo primero que se me ocurrió fue definir todos los parametros comunes como externos a cualquier clase (o como propiedades de la clase SistemaSolar; algo global, en cualquier caso), pero esto me impedía tener diferentes sistemas solares independientes, y, aunque sólo voy a hacer uno, no me gustaba (quien sabe, igual un día me da por representar toda la galaxia...).
Otra posibilidad es hacer el sistema solar con sus parámetros y pasar al constructor de los astros el objeto SistemaSolar (habría algún lío con cuál de ellos es el sol, pero bueno, nada difícil de arreglar); esta tampoco me gusta mucho porque no me parece claro que tenga que decir a qué sistema solar pertenece al crearlo, quiero decir que el sistema solar no es una propiedad de un planeta como el radio o la masa, sino que más bien es el contenedor del planeta... no sé, cosas mías.
La tercera opción "extra" que pensé (y, de estas tres, quizás la que más me gusta) es añadir un método a SistemaSolar del tipo "añadePlaneta(self, nombre, masa, radio, ...)" que me añada un planeta directamente al sistema solar; aunque básicamente sería parecida a la anterior, plantea una interfaz más evidente. Sin embargo, no me gusta no poder manipular el objeto antes de añadirlo...
Como ves, en este caso me valdría cualquiera de estas opciones, es todo más bien una cuestión de estilo, costumbre y manías; obviamente, si no hubiese encontrado manera de hacerlo con las clases anidadas lo hubiera hecho de cualquier otra forma, pero lo vi más claro así... Además, era una buena excusa para investigar algo más sobre Python, que es un lenguaje que todavía no conozco demasiado.
Me gustaría que me dijeras, si quieres, cómo lo habrías hecho tú, ya que como todo el mundo sabe hay mil formas de hacer una misma cosa, y probablemente uno nunca encuentra la mejor, de modo que acepto cualquier sugerencia, consejo o crítica
.
Un saludo
), así que no logro entender cuál es tu intención.
