Pass RestClientCache as constructor param #3222
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Relates to #2845
This has been broken out of a larger PR for ease of review.
The RestCacheClient is used in several parts of the code, but is always passed as an option. In some places (which will be changed in a subsequent PR) this is used as a form of dependency injection. However, this pattern has caused problems in some of the refactoring I am doing.
This PR changes the code so that it is passed around explicitly to the constructor methods of the structs/interfaces which need it. This is an interim step - the desired end state is that the RestClientCache is hidden from most of its current clients, and only the GitHub ProviderClassManager will depend on it (along with the Github trait instances it produces). ProviderBuilder has not been changed - that is because I am working towards getting rid of that struct.
This PR also introduces a no-op implementation of the RestClientCache interface. Previously, code had to explicitly check that it was not nil before using it. In future PRs, I will get rid of some of these guards.
Summary
Provide a brief overview of the changes and the issue being addressed.
Explain the rationale and any background necessary for understanding the changes.
List dependencies required by this change, if any.
Fixes #(related issue)
Change Type
Mark the type of change your PR introduces:
Testing
Outline how the changes were tested, including steps to reproduce and any relevant configurations.
Attach screenshots if helpful.
Review Checklist: