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

#471 Allow flexible concrete type resolution #474

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

npepinpe
Copy link
Contributor

@npepinpe npepinpe commented Mar 2, 2022

This PR introduces a new TypeResolver interface to the public API. This interface's default implementation is in ReflectionUtils, which is then delegated to the static helpers in ClassGraphFacade. This means the new feature remains backwards compatible with previous behavior.

Users can now specify a new parameter, EasyRandomParameters#typeResolver(TypeResolver), which lets them specify how concrete types will be resolved without coupling the library to ClassGraph in any way, though users can still use ClassGraph to implement it themselves.

An internal proxy class is used to wrap custom instances of TypeResolver set via the parameters. This is mostly because when creating the default ObjenesisObjectFactory, we need to pass it the current type resolver. However, it may get modified later on. So instead, we pass a proxy, which we can always modify thereafter. The proxy is not accessible to the user, so the only way to modify it is via the parameters. The downside here is that if a user modifies the parameters post-creation of EasyRandom, it will affect the internal ObjenesisObjectFactory and change the type resolver. I think that's a minor downside, as I don't expect this to be the common case, and I would hope users make use of the copy() factory method when reusing parameters. The copy() method will not copy the proxy but the actual TypeResolver, so it will really be a copy.

closes #471

npepinpe added 2 commits March 2, 2022 19:22
Introduces a new `TypeResolver` interface to the public API. This
interface's default implementation is in `ReflectionUtils`, which
is then delegated to the static helpers in `ClassGraphFacade`. This
means the new feature remains backwards compatible with previous
behavior.

Users can now specify a new parameter,
`EasyRandomParameters#typeResolver(TypeResolver)`, which lets them
specify how concrete types will be resolved without coupling the
library to `ClassGraph` in any way, though users can still use
`ClassGraph` to implement it themselves.

An internal proxy class is used to wrap custom instances of
`TypeResolver` set via the parameters. This is mostly because when
creating the default `ObjenesisObjectFactory`, we need to pass it the
current type resolver. However, it may get modified later on. So
instead, we pass a proxy, which we can always modify thereafter. The
proxy is not accessible to the user, so the only way to modify it is via
the parameters.
@npepinpe npepinpe changed the title Allow flexible concrete type resolution #471 Allow flexible concrete type resolution Mar 2, 2022
@armandino
Copy link

@npepinpe that's an interesting suggestion. I will try to implement your idea in Instancio. It's an alternative library that offers similar functionality to Easy Random. Since Easy Random is no longer maintained, I will link it here so others can find it.

https://github.com/instancio/instancio

@fmbenhassine
Copy link
Member

Thank you for your PR! I agree on the introduction of TypeResolver. However I am not a big fan a wrapping the default one in a proxy, I would keep it simple and just set the default where appropriate and make it configurable.

Please rebase the PR on the latest master and it should be good to merge. Thank you upfront.

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.

Restrict scanning for concrete types over specific packages
3 participants