-
Notifications
You must be signed in to change notification settings - Fork 0
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
Allow to shim/override members of facade #3
Labels
Comments
Goal: keep all decoration in the interface Potential syntax: public interface ITestClassFacade {
void MethodA();
[ShimProxy(typeof(TestProxy), ProxyBehaviour.MustOverride)]
void MethodB(); // Will be overridden to call new implementation which will call the base implementation
[ShimProxy(typeof(TestProxy), ProxyBehaviour.MustBeMissing)]
void MethodC(); // Provides new member implementation
}
public static class TestProxy {
public static void MethodB(ITestClassFacade inst) {
// pre-logic
inst.MethodB(); // does not recurse as "inst" is underlying
// post-logic
}
public static void MethodC(ITestClassFacade inst) {
// new logic
}
} |
Note that milestone v1.5.0 supports implemented interfaces, so some amount of additional code is possible. Example: public interface ITestClassFacade {
void MethodA();
[ShimProxy(typeof(TestProxy), ProxyBehaviour.MustOverride)]
void MethodB(); // Will be overridden to call new implementation which will call the base implementation
public void MethodC() {
// new logic using "this"
}
} |
Suggested implementation supports:
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is your feature request related to a problem? Please describe.
Some interface facades can define members that don't exist in the shimmed member. While this can be useful, it would be powerful to be able to shim new functionality in for that member.
Additionally, being able to replace the functionality of the target using the same/similar mechanism.
Describe the solution you'd like
A way to decorate the interface member so that another type can handle the instance call.
Will need to be able to call the original implementation, rather than the shim proxy.
To differentiate and prevent unexpected issues at run-time, allow to choose that will "always override" or "never override", in case an added member is implemented by the target type
Describe alternatives you've considered
Standard extension methods are useful but only allow for extending with new members.
Example
Target:
Proxy implementation example:
The text was updated successfully, but these errors were encountered: