Skip to content

PG04_Componentes

Beatrice Izabel Toth edited this page Apr 29, 2025 · 2 revisions

Paquetes con defectos

🔹 Paquete con alta complejidad – com.chess.engine.bitboards

Este subsistema presenta un número muy elevado de violaciones (más de 250), lo que sugiere un diseño de alta complejidad estructural y posiblemente una lógica fuertemente acoplada. La cantidad de errores detectados dificulta su mantenibilidad y comprensión general.

🔹 Paquete con mezcla de responsabilidades – com.chess.engine.classic.board

Este paquete agrupa entidades con funcionalidades diversas (como movimiento, transición de estados, representación gráfica), lo que indica una posible violación del principio de cohesión. Su diseño sugiere que las responsabilidades están mal distribuidas entre clases que deberían estar en paquetes distintos.

Clases con defectos

🔹 PlayerMove.java – Missing Access Modifier

La clase contiene campos sin modificador de acceso explícito, lo que reduce la claridad del encapsulamiento y puede inducir errores al ampliar el sistema. Según PMD, se recomienda declarar siempre la visibilidad de todos los miembros.

🔹 Table.java – Constructor Calls Overridable Method

Se detecta que en el constructor de la clase Table se llama a un método que podría ser sobreescrito en una subclase. Esta práctica puede producir errores si una subclase redefine ese método antes de que su estado interno esté correctamente inicializado.

🔹 Bishop.java, Rook.java, Queen.java – Código duplicado

Estas clases contienen bloques de código muy similares que podrían extraerse a un método común o clase auxiliar. Esta duplicación viola el principio DRY y dificulta el mantenimiento, ya que cualquier cambio debe replicarse en múltiples ubicaciones.

Métodos con defectos

🔹 Table.assignTileColor() – Complejidad ciclomática

Este método presenta una complejidad ciclomática superior a 10, lo que indica demasiadas decisiones lógicas (if/switch/etc.). Esto lo hace difícil de testear, mantener y comprender. Se recomienda dividirlo en varios métodos más simples.

🔹 Table.printDebugInfo() – Uso de System.out

Este método utiliza directamente System.out.println, lo cual no es adecuado para aplicaciones grandes o modulares. Se recomienda utilizar un sistema de logging configurable como Logger.

🔹 MoveUtils.java – Too Many Methods

Esta clase contiene un número excesivo de métodos (más de 20), lo que sugiere que está asumiendo más responsabilidades de las que debería. Viola el principio de responsabilidad única y puede dificultar su reutilización o refactorización.

🔹 Table.java – Message Chains (getX().getY())

La clase contiene múltiples llamadas encadenadas a métodos de otros objetos, lo que indica una violación del principio Law of Demeter. Estas dependencias profundas dificultan el cambio, ya que cualquier modificación en la cadena puede propagar errores.

🔹 Table.updateBoard() – Crear objetos en bucles

Se detecta la instanciación de objetos dentro de bucles, lo que puede generar penalizaciones de rendimiento innecesarias. Es preferible reutilizar objetos o mover la creación fuera del bucle.

🔹 Move.play() – Captura de excepciones genéricas

Se está utilizando catch (Exception e) de forma genérica. Esto es una mala práctica porque oculta errores específicos que deberían ser tratados de forma diferenciada. Se recomienda capturar únicamente las excepciones que se esperan realmente.

Biblioteca de clases

🔹 BoardUtils.java – Missing SerialVersionUID La clase implementa Serializable pero no define un campo serialVersionUID. Esto puede provocar incompatibilidades al deserializar objetos si se realizan cambios en la clase. PMD recomienda siempre incluir este identificador de versión.

PG_C02 Caracterización de aplicaciones de código con Formato ISO 9126


PG03_Valores umbrales de medidas de código


PG_C04 Evaluación de la facilidad de mantenimiento. Identificación de defectos de código.

Clone this wiki locally