#15 Tienen razón en una cosa que te comentan por aquí. En éste caso (y en general) es conveniente que trates a la clase Pregunta como una pregunta singular, no como si fuese Preguntas, y que luego utilices una estructura de datos para almacenarlas todas. E intenta que el nombre de la clase sea descriptivo: si va a contener todas las preguntas, llámala Preguntas, si se llama Pregunta, que sólo contenga una.
Una idea muy importante que te puede ayudar a comprenderlo de forma natural, es que la programación orientada a objetos (OOP) busca modelar y representar el mundo real (o contexto del problema que intentas resolver) de una forma natural.
Piensa en "programar" un coche con ruedas: Creas una clase rueda que representa una sola rueda y le das comportamiento (hinchar, girar, por decir algo), luego creas una clase coche y le pones 4 atributos rueda (y le das comportamiento al coche, por ejemplo acelerar). Date cuenta de que no estamos modelando toda la complejidad de un coche real, sólo la parte que necesitamos. Por ejemplo, mañana puedo necesitar que el coche tenga un acelerador, un freno, un freno de mano,... O igual no.
Puede darse el caso en el que necesites crear una clase "en plural", como has hecho con las Preguntas, pero es muy raro que directamente ignores la clase Pregunta que contiene una sola pregunta. Te pongo un ejemplo que utilizo últimamente:
Estás haciendo un juego 2D con el escenario en cuadrícula (vista lateral, superior o isométrica, da igual), y tienes imágenes de diferentes trozos del escenario (un trozo de suelo, una escalera, un trozo de rampa, etc, que llamamos Tiles) con los que componerlo. A esa composición la llamamos Mapa de Tiles. Podrías hacer el equivalente a lo que hiciste tú, crear una clase Tiles y dentro meter toda la representación del mapa de tiles.
Pero me resulta mucho más útil crear una clase Tile que contenga la información básica de un sólo tile (coordenadas, imagen, dimensiones, area de colisión, etc) y que me deje trabajar con él de forma individual (dibujar, actualizar, destruir, etc).
Ahora necesito tener en algún sitio la colección de tiles que representa mi escenario. Me puede servir simplemente un array de arrays de tiles (o array bidimensional) tal que Tile[][] tileMap. Y la cosa se puede quedar ahí sin ningún problema, cuando necesite algo, recorro el array, o voy a la posición que necesite e interactúo con el tile y listo. Pero nos ponemos en la situación de que yo ahora lo que quiero es que el tileMap encapsule las operaciones referentes a sí mismo.
Creo una clase TileMap, que contenga un array bidimensional de tiles y empiezo a darle comportamiento (inicializar desde fichero, dibujar todos los tiles, actualizar todos los tiles, destruir area, modificar tile, etc) y atributos que me puedan servir (area que se dibuja, loo que sea).
Cada Tile sabe como dibujarse a sí mismo, y el TileMap sabe a cuántos, cuales y en qué orden decirles que se dibujen.
Lo que te quiero decir con todos éstos ejemplos, es que tienes que intentar hacer representaciones sencillas y coherentes. Fragmenta los problemas en partes e intenta encajar esos fragmentos para que formen objetos sencillos de forma que te faciliten el trabajo. A partir de esos objetos sencillos, puedes crear otros objetos más grandes que los contengan y que se vayan encargando de tareas más generales.
#18 xDDD
#19 Suena a que está estudiando un módulo. A mi fué como me lo enseñaron cuando hice uno hace ya unos añetes: primero nos metían bases de programación y resolución de problemas (y aritmética de punteros) usando la parte más simple de C++, pero sin ver absolutamente nada de OOP; y luego enseñaban cuatro pijadas de OOP (casi ni raspar la superficie) y nos tiraban contra C# a hacer apligaciones de gestión. Me han comentado que ahora empiezan desde el principio con OOP y no se centran tanto en la parte de coger tablas en resolver problemas, pero que siguen buscando lo mismo: que empieces a hacer cosas rápidamente.
En mi caso y el de mis compañeros el resultado fué que al terminar éramos capaces de crear programas de gestión que funcionaban, pero que eran clases monolíticas de 10.000 lineas de código. La única concesión que hacíamos a la modularidad era intentar separar el código en funciones con cierta coherencia y el escaso conocimiento sobre OOP sólo nos servía para ser capaces de usar las clases de la interfaz y poco más. Luego ya por mi cuenta me metí fuerte con Objetos y empecé a usar clases como dios manda.
Ojo, seguro que no en todos sitios enseñan así el módulo, sólo describo mi experiencia.
C) y D)
