Skip to content
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

[#2076] Refactor RepoConfiguration to simplify constructor complexity #2078

Merged

Conversation

asdfghjkxd
Copy link
Contributor

@asdfghjkxd asdfghjkxd commented Dec 29, 2023

Part of #2076

Proposed commit message

Refactor RepoConfiguration to simplify constructor complexity.

Currently, the constructors for the `RepoConfiguration` class is 
very complex, involving up to 18 parameters at once, and is 
not easily extensible.

With the proposed changes, the constructor now follows the 
Builder pattern, by using a nested class `Builder` that 
helps to compose config parameters in a way that is much more 
modular and comprehensible, enhancing code quality and 
reducing confusion among developers.

However, it must be noted that `Builder` objects are not reusable as of
now, and that more combinations of arguments are permitted due to the
removal of constructors for `RepoBuilder`, which previously helped to
ensure the correctness of parameter combinations.

Let's refactor `RepoConfiguration` to simplify the 
complexity of the constructor and increase modularity 
of the code.

Other information

Apologies if this PR seems rather rough, as this is my first time contributing to an OSS, especially one at this scale!

I labelled this as a partial fix as documentation for the changes has not been made yet, and I'm not sure if that is within the scope of this issue; if required, I am happy to work on the updated documentation, before opening another pull request that seeks to address that, otherwise, I am also happy to upgrade this PR from a partial fix to a full fix.

@ckcherry23 ckcherry23 requested review from a team and MarcusTXK December 31, 2023 16:28
Copy link
Contributor

@gok99 gok99 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@asdfghjkxd kudos for taking on a relatively meaty first issue - changes are looking good and I see no significant issues so far!

for a start, let's keep the documentation changes within this PR for completion, although i suspect there isn't too much to update.

@asdfghjkxd
Copy link
Contributor Author

@gok99 I have gone back and reviewed the user/developer guides and didn't find any part that needs modification.

I believe the only documentation left would be the JavaDocs within the code itself, but all public methods and some private methods should have their JavaDocs already furnished!

@ckcherry23 ckcherry23 requested a review from a team January 8, 2024 06:37
@asdfghjkxd asdfghjkxd requested a review from a team January 23, 2024 16:46
Copy link
Member

@MarcusTXK MarcusTXK left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@asdfghjkxd Great work on this! I was really impressed that you tackled this as your first issue. I think you did a very good job refactoring it into the new builder pattern and making sure to capture all the logic carefully.

I've added some comments as minor nitpicks. Additionally, it would be good if you could address some of these new lines that Codecov flagged as not covered by tests.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For lines 38 - 39, new ArrayList<>() Initializer for ignoreGlobList and ignoredAuthorsList is now redundant

Comment on lines 270 to 279
/**
* Updates the {@code fileTypeManager} for {@code RepoConfiguration}.
*
* @param fileTypeManager List of file types and groupings permitted.
* @return This builder object.
*/
public RepoBuilder fileTypeManager(FileTypeManager fileTypeManager) {
this.fileTypeManager = fileTypeManager;
return this;
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consider accepting a List<FileType> directly in the builder and internally creating the FileTypeManager, for simplicity and maintainability. This way, we encapsulate FileTypeManager creation and make the API easier for users, keeping the builder's usage clean and hiding unnecessary complexity.

public RepoBuilder formats(List<FileType> formats) {
    this.fileTypeManager = new FileTypeManager(formats);
    return this;
}

@MarcusTXK MarcusTXK requested a review from a team January 29, 2024 08:19
@asdfghjkxd
Copy link
Contributor Author

@MarcusTXK Sure thing, I will work on it and add a new commit here once I'm done fixing the code and creating new test cases!

@asdfghjkxd
Copy link
Contributor Author

I have also made some changes to the way the processName and processOrganisation works, whereby if specified by RepoBuilder, the folder name, output folder name and display name will change to the one that is provided by RepoBuilder, rather than defaulting to the default names given to those 3 variables.

I believe that this was an oversight on my part and I had failed to implement checks and allow RepoBuilder configurations to override the default configuration.

This behaviour should be fixed now in the new commit!

Copy link
Contributor

@gok99 gok99 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sorry about the review delays! have left some suggestions and discussion points - feel free to comment :)

src/main/java/reposense/model/RepoConfiguration.java Outdated Show resolved Hide resolved
src/main/java/reposense/model/RepoConfiguration.java Outdated Show resolved Hide resolved
src/main/java/reposense/model/RepoConfiguration.java Outdated Show resolved Hide resolved
*/
private void processNames(RepoBuilder repoBuilder) {
String repoName = this.location.getRepoName();
this.displayName = repoBuilder.displayName == null
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would an Optional be a good idea for these? we probably should be using more Optionals in RepoSense to enforce a check, but that's a separate discussion...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree, Optional would eliminate the == null checks, making the code a lot more understandable and readable! Will look into usingOptional here!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we look into creating an issue for these separately?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@MarcusTXK I agree, most of the issues we had discussed above are rather complicated (parameter verification, duplication of RepoConfiguration, etc.) and seem to warrant the creation of separate issues.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I think we can focus on improving the RepoConfiguration incrementally, as @gok99 has brought up alot of good points.

@asdfghjkxd
Copy link
Contributor Author

asdfghjkxd commented Feb 4, 2024

I'm reverting the changes back to before the refactor, it seems like something has caused all the system test cases to break.

EDIT: After looking through the code, it seems that there was some mistake in how processOrganization handled the different names of the RepoConfiguration object. This issue has been resolved and the code will be updated back to where it originally was.

@asdfghjkxd asdfghjkxd force-pushed the enhancement-repoconfig-builder-pattern branch from 07c7506 to a50e488 Compare February 4, 2024 14:27
@asdfghjkxd asdfghjkxd requested a review from gok99 February 5, 2024 02:55
Copy link
Contributor

@gok99 gok99 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks for the work!

Copy link
Member

@MarcusTXK MarcusTXK left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, great job with this PR!

@ckcherry23 ckcherry23 merged commit d2018d2 into reposense:master Feb 16, 2024
10 checks passed
Copy link
Contributor

The following links are for previewing this pull request:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants