javadevone / juego-2d-java Goto Github PK

issue.pdf

Es como si no pudiera cargar ningun recurso, me da error primero de la Fuente y luego de las imagenes de la siguiente manera:

java.io.IOException: Problem reading font data. at java.desktop/java.awt.Font.createFont0(Font.java:1208) at java.desktop/java.awt.Font.createFont(Font.java:1076) at principal.herramientas.CargadorRecursos.cargarFuente(CargadorRecursos.java:103) at principal.Constantes.<clinit>(Constantes.java:43) at principal.GestorPrincipal.main(GestorPrincipal.java:43) java.io.IOException: Stream closed at java.base/java.io.BufferedInputStream.getInIfOpen(BufferedInputStream.java:157) at java.base/java.io.BufferedInputStream.fill(BufferedInputStream.java:244) at java.base/java.io.BufferedInputStream.read(BufferedInputStream.java:263) at java.desktop/com.sun.media.sound.RIFFReader.read(RIFFReader.java:126) at java.desktop/com.sun.media.sound.RIFFReader.<init>(RIFFReader.java:61) at java.desktop/com.sun.media.sound.WaveExtensibleFileReader.getAudioFileFormatImpl(WaveExtensibleFileReader.java:172) at java.desktop/com.sun.media.sound.SunFileReader.getAudioFileFormat(SunFileReader.java:54) at java.desktop/com.sun.media.sound.WaveExtensibleFileReader.getAudioInputStream(WaveExtensibleFileReader.java:259) at java.desktop/javax.sound.sampled.AudioSystem.getAudioInputStream(AudioSystem.java:1010) at principal.herramientas.CargadorRecursos.cargarSonido(CargadorRecursos.java:123) at principal.sonido.Sonido.<init>(Sonido.java:13) at principal.GestorPrincipal.<init>(GestorPrincipal.java:23) at principal.GestorPrincipal.main(GestorPrincipal.java:43) Exception in thread "main" java.lang.IllegalArgumentException: input == null! at java.desktop/javax.imageio.ImageIO.read(ImageIO.java:1402) at principal.herramientas.CargadorRecursos.cargarImagenCompatibleTranslucida(CargadorRecursos.java:50) at principal.control.Raton.<init>(Raton.java:33) at principal.graficos.SuperficieDibujo.<init>(SuperficieDibujo.java:31) at principal.GestorPrincipal.inicializar(GestorPrincipal.java:57) at principal.GestorPrincipal.iniciarJuego(GestorPrincipal.java:52) at principal.GestorPrincipal.main(GestorPrincipal.java:46)

Asunto: Tarea4 - Code Smell Nota: Es parte de un deber, siéntete libre de ignorar.
CodeSmell: Data Clumps

Justificación de Problema: Los datos posicionX y posicionY se pasan como parámetros repetidamente en varios métodos de la clase enemigo. Esto indica que estos datos deberían ser encapsulados.

Refactorizacion: Replace data value with object
Solución: Reemplazar las variables posicionX y posicionY por un objeto Coordenada, que encapsula las coordenadas x e y y proporciona métodos para operaciones relacionadas.
Nota: Esto es un ejemplo de como organizarlo.

Beneficios de Refactorizar: Ayuda a reducir la cantidad de código utilizado en la clase Enemigo al mejorar la organización y estructura del mismo. Mejora la claridad de compresión del código y simplifica los métodos que los usan. Este tipo de objeto es utilizado en algunas partes del programa por lo que se podría reutilizar.

Hola estuve revisando el código de tu juego y noté algo raro en la parte en cómo esta creado el inventario. El siguiente diagrama de clases corresponde al diseño actual del inventario:

Lo que podemos notar aquí es una mala estructura del inventario puesto que no podemos saber muy bien como este se relaciona con el contenedor o incluso con los objetos únicos. De la misma manera se ve que se podría implementar el patrón Composite para poder ordenar mejor esta estructura y evitar problemas futuros al querer acceder desde alguna otra clase a los objetos del inventario.

Le propongo implementar la siguiente solución que nos ayuda a relacionar todos los tipos de objetos y el contenedor de ellos con el inventario.

De esta manera vemos como el inventario directamente tendría instancias de cualquiera que implemente esta interfaz y no solo de un objeto como se encontraba anteriormente dándonos la ventaja de poder acceder a dichos objetos con mayor facilidad.

Asunto: Tarea4 - Code Smell Nota: Es parte de un deber, siéntete libre de ignorar.
CodeSmell #5: Feature Envy

Justificación de Problema: La clase jugador tiene los métodos de determinarDirección, evaluarVelocidadX, evaluarVelocidadY solo usa métodos de la clase GestorControles y no métodos propios en estos. Por lo que los métodos en cuestión están “envidiando” ciertas funcionalidades de otro objeto. Además, tener estos métodos dentro de la clase jugador hace que el código en esta sea más extenso. Esto nos sugiere que los métodos deberían ser parte de la clase GestorControles.

Solución: Mover dichos métodos a GestorControles en donde tenga mas sentido su uso sin que Jugador tenga que “envidiar” la funcionalidad de otra clase. También se agrega una llamada al método determinarDirección dentro de la clase jugador para poderlo usar.
Nota: Esto es un ejemplo de como organizarlo.

Beneficios de Refactorizar: Se mejora la cohesión de ambas clases al tener una responsabilidad especifica y solo hacer uso de llamadas a métodos. Hace más sencillo modificar una clase sin afectar a otra. Mejora la legibilidad del código y disminuye la cantidad de líneas de código dentro de las clases lo que hace más sencillo la corrección de errores.

Asunto: Tarea4 - Code Smell Nota: Es parte de un deber, siéntete libre de ignorar.

CodeSmell: Large class
Repositorio: juego-2d-java
Justificación de Problema: La clase Dijkstra contiene varios métodos que ejercen diferentes funcionalidades. La acumulación de métodos podría llegar a complicar el entendimiento de la clase. Es posible también que se complique la reutilización de código en otras partes del programa lo que podría llevar a la necesidad de mantenimiento al código.
Las responsabilidades de los diferentes métodos van desde el constructor, la obtención del nodo, evaluación del mapa del juego, encontrar nodos vecinos.

Técnica de refactorización: Extract Class
Solución:
Pasamos de tener una sola clase con muchas funciones a subdividirlas en clases más pequeñas y específicas.
Nota: Esto es un ejemplo de como organizarlo.

Beneficios de Refactorizar: Dividir la clase en otras más pequeñas facilitara la comprensión del código de manera que se facilitara la reutilización de código dentro del programa. Facilita el mantenimiento del programa al contar con clases más simplificadas y especificas sin que los cambios afecten a otras partes del código.

Hola, estuve revisando el código de tu juego, el cual me gustó mucho, y quisiera dar una recomendación que tiene que ver en cómo se crean los enemigos. Quise ver un posible crecimiento futuro del juego en donde se vea necesario la creación de nuevos enemigos o simplemente darles clases diferentes. Para eso yo sugiero el implementar el patrón de diseño llamado Builder que nos permitirá crear nuevos enemigos de diferente clase de una forma rápida. A continuación, se ilustra el diagrama de clases surgido al momento de implementar el Builder:

Como se nota en la solución propuesta, nuestro diagrama de clases se extendió mucho respecto al que teníamos anteriormente debido a que se añadieron tres nuevas clases, pero, aunque al principio puede ser un poco difícil de entender, obtendremos muchos beneficios al momento de querer crear nuevos enemigos sin la complejidad que implica crear todos los tipos disponibles desde cero.

The following is just a homework assignment about trying to implement Refactoring in old Java Software. Please do ignore it if You wish because its not something done by a professional o someone that knows what they are doing. Sorry to have bother you.
Nueva carpeta (13).zip