-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactoring Suggestion - Address Class #142
Comments
9 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
THIS ISSUE IS POSTED AS A COLLEGE ASSIGNMENT ON BAD CODING SMELLS AND REFACTORING TECHNIQUES. PLEASE CLOSE THE ISSUE IF IT IS OF NO USE.
Hi shashirajraja,
I hope this message finds you well. After reviewing the Address class in your codebase, I wanted to propose a potential improvement and suggest incorporating the "Remove Setting Method" refactoring technique.
Why Refactor?
Encapsulation and Cohesion: The current class primarily acts as a data holder, and adding meaningful behavior to the class can enhance encapsulation and cohesion.
Maintainability: By introducing constructor-based initialization and removing setter methods, you improve the class's predictability and make it easier to maintain.
Avoiding Redundancy: Implementing methods like equals(), hashCode(), and providing a custom toString() can contribute to a cleaner, more organized design.
Refactoring Proposal:
By removing the setter methods, the class becomes immutable, which has several advantages, including improved thread safety and reasoning about the state of objects.
Feel free to incorporate this suggestion and reach out if you have any questions or need further clarification.
The text was updated successfully, but these errors were encountered: