Reduce number of Parser classes

[EFregnan]

While working to expand the functionalities supported by the API, I noticed that so far we have followed the paradigm of having one Parser class per data type to extract: e.g., one for CommentInfo entities, one for CommitInfo entities, and so on.

However, this adds a lot of load in terms of parameters passed to the constructor of some classes (for example, ChangeApiRestClient or RevisionApiRestClient).
I think it would good to do something about it.

I would propose to cluster together related methods in a "bigger" parser class: e.g., we could have a ReviewerParser class that groups together the classes AddReviewerResultParser, SuggesterReviewerInfoParser, and ReviewerInfoParser.

What do you think? I believe it would benefit the usability of the code to improve this.
Also, I am open to any suggestion on how to do this.

Thank you!

[uwolfer]

Sounds like an idea - would you like to do that for one example cluster, and then I can take a look?

[EFregnan]

Sure, I will create a first "cluster" of parsers and open a PR so you can have a look.

[EFregnan]

I added a PR with an example of clusters. I think that proceeding in a similar fashion we could cut the number of parameters in the constructors of ChangeApiRestClient or RevisionApiRestClient without losing too much in terms of understandability of the code.

Let me know what you think.

[EFregnan]

@uwolfer, I would like to add a folder parsers in gerrit-rest-java-client/src/main/java/com/urswolfer/gerrit/client/rest/http/changes/ to separate parser classes from the other classes (e.g., ChangeApiRestClient.java).

What do you think?

[uwolfer]

@uwolfer, I would like to add a folder parsers in gerrit-rest-java-client/src/main/java/com/urswolfer/gerrit/client/rest/http/changes/ to separate parser classes from the other classes (e.g., ChangeApiRestClient.java).

What do you think?

Sounds reasonable to me.