Hey, hay otra historia para contar. Por favor, no te rias. ¿Qué será? Pues es que esta historia trata de uno de los errores más ridículos que te pueden ocurrir cuando comienzas a programar en Java. Y es que cuando uno programa en Java debe tener en cuenta que el JDK debe estar instalado para que los programas se compilen y ejecuten (a menos que utilices un IDE que lo instala por defecto). Bueno, pero en nuestro caso, no utilizamos ningún IDE así que sólo teníamos instalado nuestro editor -Notepad++- y escribimos todo el código para nuestra clase Data.java. No es una clase muy grande, pero estábamos muy emocionados por que la mayor parte del código complejo –Tablero.java- ya estaba funcionando, y para terminar con la estructura y ejecución del juego en sí mismo (nada de presentación visual) sólo nos faltaba Data.java. Escribimos todo el código, lo añadimos a la clase Interfaz .java y estábamos listos para compilar y ejecutar. Abrimos la línea de comandos, nos dirigímos a la carpeta donde estaban nuestros archivos y escribimos el omnipotente y omnipresente javac Data.java. Habia tensión en el ambiente, todo el bullicio de la gente desapareció, nuestras pupilas se dilataron, el corazón latía fuertemente: presionamos enter…
“javac” no se reconoce como un comando interno o externo, programa o archivo por lotes ejecutable…
¡ Noooooooooooo! ….le pregunte a Pablo si tenía instalado JDK en su portátil, y su respuesta fue muy sincera: “mmmm nop”. Nos reímos por un buen rato. De todos modos, luego de instalar el JDK, no compilo el programa. El error era que no habíamos cerrado una llave, y luego, compiló. Gracias a Dios! De ahora en adelante, estas situaciones no volverán a ocurrir.
Lo que más nos costo...
Una de las fases de la programación que más nos gusto fue el análisis realizado para saber si, luego de que el jugador ha presionado 4 botones, verificar si estos forman un cuadrado y si son del mismo color, y de cumplir ambos requisitos, modificarlo los botones dentro de ese cuadrado. Al principio nos parecia una tarea fácil, por que simplemente recaudabamos las coordenadas y comparabamos, comparamos también los colores y ya. Pero al momento de escribir el código nos dimos cuenta que efectivamente, lo anterior era lo que el código debia hacer, pero el simple hecho que lo hiciera se nos hizo complejo. Recurrimos a algunas técnicas matemáticas e incluso alguna vez pasó por nuestra mente tomar las coordenadas como componentes de vectores, lo cual era poco funcional. Sin embargo se nos ocurrió algo muy lógico: Si 4 botones formaban un cuadrado, se podia elejir uno al azar y debia haber otro a la izquierda o derecha de él (misma fila) y otro abajo o arriba de el (misma columna); si se cumplian las dos condiciones anteriores, también se verificaba una tercera: que hubiera un boton seleccionado que coincidera con la fila del boton que esta arriba o abajo del boton inicial, y que concidiera con la columna del botón que esta a la izquierda o derecha del boton inicial. Luego, si las condiciones anteriores se cumplian, simplemente se verificaba que el color de los botones en dichas coordenadas fuera igual.
Lo que más nos costo...
Una de las fases de la programación que más nos gusto fue el análisis realizado para saber si, luego de que el jugador ha presionado 4 botones, verificar si estos forman un cuadrado y si son del mismo color, y de cumplir ambos requisitos, modificarlo los botones dentro de ese cuadrado. Al principio nos parecia una tarea fácil, por que simplemente recaudabamos las coordenadas y comparabamos, comparamos también los colores y ya. Pero al momento de escribir el código nos dimos cuenta que efectivamente, lo anterior era lo que el código debia hacer, pero el simple hecho que lo hiciera se nos hizo complejo. Recurrimos a algunas técnicas matemáticas e incluso alguna vez pasó por nuestra mente tomar las coordenadas como componentes de vectores, lo cual era poco funcional. Sin embargo se nos ocurrió algo muy lógico: Si 4 botones formaban un cuadrado, se podia elejir uno al azar y debia haber otro a la izquierda o derecha de él (misma fila) y otro abajo o arriba de el (misma columna); si se cumplian las dos condiciones anteriores, también se verificaba una tercera: que hubiera un boton seleccionado que coincidera con la fila del boton que esta arriba o abajo del boton inicial, y que concidiera con la columna del botón que esta a la izquierda o derecha del boton inicial. Luego, si las condiciones anteriores se cumplian, simplemente se verificaba que el color de los botones en dichas coordenadas fuera igual.
Lo anterior pasó de ser una tarea facil a una tarea mental muy complicada y nos enseño que pasar de la mente al código puede ser una verdadero reto.
Lo que más impresionante...
Lo más impresionante que programamos son las clases botón y tablero, que son las que permiten el juego. La clase Boton.java estaba muy clara desde el principio, y sus atributos (simbolo, selected, la imagen) también estaban bien definidos tanto qué eran como la forma en que se iban a modificar al transcurrir el juego. La clase Tablero.java es una de las clases más grandes, pero cada sección del código está muy bien pensada, y en nuestra opinión, es un código muy eficaz. Tablero es una clase que hereda de JPanel, es decir, es una subclase de la superclase JPanel. Por tanto Tablero es un contenedor, y al serlo, podemos agregar objetos de la clase Boton.java, que a su vez son una subclase de la superclase JButton. El tablero completo es una colección, más bien matriz de objetos Boton, que estan contenidos en un objeto Tablero, distribuidos en filas y columnas. Y uno, teniendo unicamente las clases Boton y Tablero, puede jugar Blocky, aunque, por supuesto, las clases Blocky.java, Data.java e Interfaz.java permite crear una GUI amigable y dinámica con el usuario.
Lo más emocionate fue...
Creo que todos los que iniciamos con Java, estaríamos de acuerdo en decir que lo más emocionante al hacer un programa en Java es el momento cuando uno escribe javac clase.java y presiona enter. La respiración se detiene, las manos comienzan a sudar, y se siente que el tiempo transcurre más lentamente, los ruidos desaparacen: ningun mensaje de error!!!! wujuuuuuu!!!!!!. Pero además de esos momentos, en nuestro caso, lo más emocionante fue ver la forma que en que cada clase interactuaban y como realemente pudimos resolver el problema que teniamos en terminos del problemo, y no necesariamente en terminos del código que utilizamos. La programación orientada a objetos es realmente orientada a objetos, y son objetos que uno los puede hacer parecer tan reales como uno quiera. En este proyecto se reunió todos los conocimientos adquiridos en las clases magistrales como en el laboratorio, y en las etapas de investigación propia, y de esos conocimientos surgió una replica muy buena del juego Blocky. Entender cómo es que las clases y sus métodos interactuan, y como una clase es una conceptualiación de un objeto, fue simplemente maravilloso. Nos pareció que cuando uno llega a comprenden lo dicho anteriormente, se siente que el resto de la programación ya no puede ser más complicado.
Lo más impresionante que programamos son las clases botón y tablero, que son las que permiten el juego. La clase Boton.java estaba muy clara desde el principio, y sus atributos (simbolo, selected, la imagen) también estaban bien definidos tanto qué eran como la forma en que se iban a modificar al transcurrir el juego. La clase Tablero.java es una de las clases más grandes, pero cada sección del código está muy bien pensada, y en nuestra opinión, es un código muy eficaz. Tablero es una clase que hereda de JPanel, es decir, es una subclase de la superclase JPanel. Por tanto Tablero es un contenedor, y al serlo, podemos agregar objetos de la clase Boton.java, que a su vez son una subclase de la superclase JButton. El tablero completo es una colección, más bien matriz de objetos Boton, que estan contenidos en un objeto Tablero, distribuidos en filas y columnas. Y uno, teniendo unicamente las clases Boton y Tablero, puede jugar Blocky, aunque, por supuesto, las clases Blocky.java, Data.java e Interfaz.java permite crear una GUI amigable y dinámica con el usuario.
Lo más emocionate fue...
Creo que todos los que iniciamos con Java, estaríamos de acuerdo en decir que lo más emocionante al hacer un programa en Java es el momento cuando uno escribe javac clase.java y presiona enter. La respiración se detiene, las manos comienzan a sudar, y se siente que el tiempo transcurre más lentamente, los ruidos desaparacen: ningun mensaje de error!!!! wujuuuuuu!!!!!!. Pero además de esos momentos, en nuestro caso, lo más emocionante fue ver la forma que en que cada clase interactuaban y como realemente pudimos resolver el problema que teniamos en terminos del problemo, y no necesariamente en terminos del código que utilizamos. La programación orientada a objetos es realmente orientada a objetos, y son objetos que uno los puede hacer parecer tan reales como uno quiera. En este proyecto se reunió todos los conocimientos adquiridos en las clases magistrales como en el laboratorio, y en las etapas de investigación propia, y de esos conocimientos surgió una replica muy buena del juego Blocky. Entender cómo es que las clases y sus métodos interactuan, y como una clase es una conceptualiación de un objeto, fue simplemente maravilloso. Nos pareció que cuando uno llega a comprenden lo dicho anteriormente, se siente que el resto de la programación ya no puede ser más complicado.
No hay comentarios:
Publicar un comentario