abdullahshahid01 / rent-a-car-management-system Goto Github PK

Buenas noches. He podido notar que su código presenta un code smells de Comments en la clase CarOwner. El mantener este olor en el método update() provoca que no se fácil entender el propósito de partes del código sin la presencia de los comentarios. Lo que significa que el código es poco intuitivo y obvio. Se recomiendo usar la técnica de refrectoring para solucionar este smell.

Buenas noches. Quisiera reportar de un code smell en la clase Car. El código actual presenta una sobre dependencia a las clases primitivas para representar cualidades del objeto carro. El usar los atributos nombre, tipo, maker, color y modelo como strings puede causar que el código se vuelva poco flexivo y más difícil de operar. Además de que esparcirá los atributos del objeto por todo el código, lo que lo hará más difícil de corregir y entender. Se recomienda usar las técnicas de refrectoring de Replace Type Code With Class e Introduce Parameter Object

the proper documentation should be there ...username and password.. database file

Buenas tardes, quisiera hacerle una recomendación. Entre la clase "Person", "CarOwner" y "Customer" debería de hacer uso del patrón de diseño creacional Factory Mehtod. Esto permitiría que las subclases alteren el tipo de objeto a crear, haciendo mas extensible el código y dejando que la nueva clase "PersonFactory" sea la encargada de la compleja creación de objetos.

Existen valores como el CNIC y el Contact_No tratadois como datos primitivos, los cuales deberían ser considerados como objetos pequeños, se recomienda usar la técnica de refactoring Replace Data Value with Object.

Buen dia. He encontrado violacion con respecto a este principio, y es que la clase Person, contuene los metodos isCNICValid, isContactNoValid, isNameValid, isIDvalid, puesto que las lases hijas que heredan de esta no implemnetan. Esta estrechamnete relacionado con el principio ISP, pero es que practicamente esta clase peadre no puede comportarse como las hijas. Mi recomendacion es una interfaz isValid, para que solamente lo implemente el padre

Buenas tardes, quisiera hacerle una recomendación. He podido notar que en su proyecto, en la clase "Car" específicamente, se incumple con el principio de responsabilidad única ya que los metodos “isNameValid”, “isRegNoValid” tienen otro tipo de responsabilidad que no debería tener la clase "Car". Mi recomendación de solución seria trasladar dichos métodos a otra clase para que así cada una tenga un solo tipo de responsabilidad.

hello bro i dont know if you could assist me this project is giving 170 errors when i run it in vscode for example The import org.netbeans cannot be resolved i dont know what to do to fix this may you please assist

Buenas tardes, quisiera hacerle una recomendación. En la clase CarOwner.java y Customer.java se incumple con el principio de abierto-cerrado ya que el método “Remove” es muy parecido en ambos casos y, en caso de modificación, habría que hacerlo en ambas clases; así el código no estaría abierto a extensiones. Sin embargo, una posible solución seria mover dicho método en otra clase para que, en caso de modificación, realizar los cambios en la nueva clase.

Buenas tardes, quisiera hacerle una recomendación. En la clase Person.java se incumple con el principio de sustitución de Liskov ya que en el caso de que existiera una clase como "GerenteDeLocal", el cual hereda de Persona, este no debería de implementar los métodos de "Add" o "Remove" ya que en su caso solo se lo puede despedir o actualizar sus datos. Una solución a esto seria crear una interface para cada uno de estos métodos, provocando que no sea obligatorio para la clase "GerenteDeLocal" implementar los métodos "Add" o "Remove".

Buenas tardes, quisiera hacerle una recomendación. He podido notar que en su proyecto, en la clase "Car" específicamente, se incumple con el principio de responsabilidad única ya que el método “isRented” cumple con una responsabilidad diferente a la que realmente tiene la clase "Car". Por ende, le recomendaría que incluya dicho método en una clase aparte cumpliendo con el principio de responsabilidad única.

Buenas tardes, quisiera hacerle una recomendación. He podido notar que en su proyecto, en la clase "Car" específicamente, se incumple con el principio de responsabilidad unica ya que los metodos “SearchByName”, “SearchByID” y “SearchByRegNo cumplen con otro tipo de responsabilidad. Mi recomendación de solución seria trasladar dichos métodos a otra clase cumpliendo con el principio mencionado.

Existe un code smell, debido a que se está utilizando fragmentos de código similares en distintas partes del código, se recomienda usar extract method.

Buenas tardes, quisiera hacerle una recomendación. He podido notar que en su proyecto, en la clase CarOwner.java y Customer.java específicamente, se incumple con el principio de abierto-cerrado debido a que el método “View” es muy parecido en ambos casos y, en caso de modificación, habría que hacerlo en ambas clases. Por ende, mi recomendación seria trasladar este método a una sola clase volviendo el código menos complejo.

Buen dia. He revisado su codigo y tiene algunas violaciones al principio SOLID, el DIP que trata de que los high-level clases dependan de abstracciones no de objetos concretos. Mi recomendacion es que separe en una interfaz aparte por ejemplo los metodos update(), add(), remove(), que se encuentran en comun en algunas clases. Esta fue una primera violacion de este principio.
La Segunda Violacion es de la misma manera en la clase Booking, con los metodos searchbycarregno, searchbycraid, searchbycustimerid. por si en el futuro hay alguna modificacion en la interface serializable solmanete tendria que modificar lo que extienda de ella, ya no en la clase directamente.

Buen dia. He encontrado violacion en este principio. Me refieron a la clase Booking, que se encuentra el metodo calculateBill(), por lo que no se ve que este metodo es una responsabilidad a esta clase. Suguiero que esta clase lo ponga una interfaz