leecottrellptc / javaooplectures2020 Goto Github PK

En el método toString() de la clase Persona se encuentra una secuencia de condicionales para definir como se va a llamar a una persona dependiendo de sus géneros. Pienso que en esta parte podría ser beneficioso utilizar una estructura diferente, pues si en algún momento se requiere añadir nuevas funciones que dependan del género será beneficioso tener clases aparte que definan este comportamiento en lugar de manejarlo con Strings. A continuación adjunto propuestas para refactorizar esto usando la técnica replace type code with state/strategy.

En todo el proyecto existen comentarios redundantes que tratan de explicar el funcionamiento, motivos y detalles de una clase, método o parámetro. Al hacer eso se pierde cierta limpieza y sobre todo "clase" en el código y da la impresión que este no es lo suficientemente intuitivo para explicarse a si mismo. Lo mejor sería borrarlos y tratar de mejor el nombre de cada cosa con el fin de justificarse.

Dentro del proyecto hay un paquete que contiene una clase completamente vacía a excepción de un método main. No estoy muy seguro de si este código tenía algún propósito que aún no se ha implementado o si simplemente es un error, de todas formas esto se debería corregir pues actualmente solo causa confusión y le quita legibilidad al código. Se recomienda en este caso que simplemente se borre la clase o por lo menos darle un propósito. Adjunto una imágen del error.

En la clase que se ha definido para las pizzas en el paquete de pizzaGUI hay demasiados elementos, esa clase no debería ser tan grande. Pienso que si se mantiene la estructura actual será muy difícil de mantener y agregar nuevos aspectos a la clase de Pizza, los toppings que existen en este momento solo funcionan como flags, lo cual tampoco es correcto. En el caso de la manera en la que se maneja el precio, al depender del tamaño estos se deberían delegar a otra clase. Por estas razones se recomienta separar las clases usando extract interface y class, para que se obtenga el siguiente resultado.

La clase pizza tiene todos sus atributos en default, esto no es una buena práctica sobre todo al considerar que ya se ha construído getters y setters para la mayoría de estos atributos. Es recomendable encapsular estos elementos, se está desaprovechando uno de los pilares de la programación orientada a objetos. Al tener estos elementos en privado se podrá mantener una mejor seguridad sobre los mismos. La solución a este problema es simple, se recomienda encapsular los campos de la clase.

Hay un atributo en la clase de Book que no cumple ninguna función fuera de tener un getter y un setter. Este atributo se pudo colocar pensando en las características de un libro o en una funcionalidad futura, sin embargo por ahora no hace nada, entonces sería beneficioso simplemente removerlo. Se debe usar remove parameter para eliminarlo de los pocos métodos que lo utilizan. Adjunto los cambios propuestos.

Se usan bastantes tipos de parametros primitivos en el proyecto, por ejemplo la clase WriteFile tiene como parámetros fname, lname, username, password, los cuales son Strings y tranquilamente podrían pertenecer a una clase credencial con el motivo de usar objetos en la WriteFile. De esta manera se solucionan los problemas de desorganización y escalabilidad.