search

OSSpk / Library-Management-System-JAVA

📚 A sophisticated Library Management System designed in Java while following the concepts of decoupled layers (entities) and minimal code in interface (GUI).
https://github.com/harismuneer
MIT License
353 stars 231 forks source link

[ImgBot] Optimize images #3

Closed imgbot[bot] closed 3 years ago

imgbot[bot] commented 5 years ago

Beep boop. Your images are optimized!

Your image file size has been reduced by 21% 🎉

Details | File | Before | After | Percent reduction | |:--|:--|:--|:--| | /images/final.png | 42.14kb | 33.40kb | 20.75% |

📝docs | :octocat: repo | 🙋issues | 🏅swag | 🏪marketplace

carlosamr2 commented 4 years ago

sugerencia: cambiar la clase staff por una interfaz y las clases clerk y librarian la implementan vuelve al codigo mas optimo

carlosamr2 commented 4 years ago

Hola, recomiendo el uso de los siguientes patrones para mejorar la estabilidad de tu codigo:

Observer: se utiliza el patron oberserver para notificar cuando un libro ha sido prestado o debe ser retenido por reparaciones y asi notificar al sistema de su ausencia y que no puede ser prestado

Factory Method: se utiliza el factory method ya que si en el futuro se desea prestar no exclusivamente libros, sino tambien revistas, papers, tesis, etc. el sistema debe poder responder a estos cambios sin alterar desmedidamente el codigo

Decorator: utilizamos un decorator ya que puede darse el caso de que un cliente se convierta en un empleado o que un empleado alquile libros de la libreria y el programa debe responder adecuadamente en caso de que se presente esta “duplicidad” de registros

carlosamr2 commented 4 years ago

Hola he notado que tu codigo contiene ciertos code smells y adjunto posibles soluciones:

comments: Una de las reglas es que la librería solo puede tener un único bibliotecario, el método addLibrarian se encarga de revisar que exista y agregarle uno, pero necesita expresar en un comentario la regla descrita previamente, por ello es mejor aplicar un Extract Method para verificar esto aparte y volver el código más legible.

primitive obsession: La clase Library está utilizando datos de tipo int para calcular fechas máximas de devolución para los libros de la biblioteca, lo que podría dificultar la forma de calcular los límites y agregar código innecesario. Este problema se puede solucionar con un Replace Data Value With Object.

lazy class: la clase HoldRequest solo posee un constructor, getters y setters, se encarga de marcar un libro como prestado cuando alguien lo solicita en la biblioteca, sin embargo es una clase que no hace mucho ya que serán pocos libros lo que se encuentren prestados a diferencia de los disponibles, sería mejor que desapareciera y la clase Loan los marcara como prestados ya que esta es la clase que manipulas los préstamos de libro y se aplicará un Inline Class

harismuneer commented 3 years ago

@carlosamr2 Hi, thank you for the great suggestions. Can you kindly do this refactoring and generate a PR, that would be really awesome!