I’m looking at ways to improve the consistency, brevity, and readability of some code in the application I’m working on. The starting code looked something like this:
context.GetGraphType<Bar>().Subscribe<Fizz>(
(instance, evt) => evt.Execute((Bar)instance.Instance)
);
There are a number of nearly identical lines of code like the above. I wanted to rewrite it to look something like this:
typeof(Bar).SubscribeTo<Fizz>(context);
For one thing, this would allow me to take advantage of formalizing what had already become an informal convention. Also, I hoped that it would now read something like “bar subscribes to the fizz event on the given context”, rather than “the context gets the bar type and subscribes to fizz and then does some stuff.” I think that the flow is better, and the coworker I asked about it agreed.
I started to implement this as an extension method. In order to accomplish the above I wanted to make use of an abstract generic base class for the event type, so Fizz
would be Event<T>
. This would mean that the generic type argument to the extension method would have to be constrained to be of the type that the extension method is called for. So, for the above example, Fizz
would have to be of type Event<Bar>
.
Is this possible? I went with an alternative solution in the mean time, but I am still curious if it can be accomplished. Other suggestions are welcome as well.
Thanks!
Edit #1: Just to be clear, I realize that I could use an additional type parameter, but I'm looking for ways to avoid that if possible.
Edit #2: I think I'm going to go with a slight variation of the accepted answer, since it doesn't match up 100% with my scenario. The bottom line is that a generic static class can be used instead of an extension method of Type to accomplish my goal. Thanks dss539!
Update code (there may be typos since I'm doing this on the fly):
public class Bar { }
public class Event<TSubscriber>
{
public abstract void Execute(TSubscriber source);
}
public class Fizz : Event<Bar>
{
public override void Execute(Bar bar)
{
// respond to event
}
}
public class Context { }
public static class ForType<TSubscriber>
{
public static void SubscribeTo<TEvent>(Context context)
where TEvent : Event<TSubscriber>
{
context.GetType<TSubscriber>().Subscribe<TEvent>(
(evt, args) => evt.Execute((TSubscriber)args.Source));
}
}
public static void Run()
{
ForType<Bar>.SubscribeTo<Fizz>(context);
}
This is not exactly like you asked, but maybe it will suffice.
internal class Program
{
static void Main(string[] args)
{
var fizzHandler = new Fizz();
var context = new Context();
Handle<Bar>.With(fizzHandler, context);
}
}
public class Bar { }
public class Event<T> { }
public class Fizz : Event<Bar> { }
public class Context { };
public static class Handle<T>
{
public static void With(Event<T> e, Context c)
{
//do your stuff
}
}
Why not do something a bit more idomatic, where you could use generic constraints to enforce the rules:
public static class SubscriptionManager
{
public static void SubsribeTo<TSub,TEvent>( Context context )
where TEvent : Event<TSub>
{
/// you code...
}
}
The calls would look like:
SubscriptionManager.SubsribeTo<Bar,Fizz>( context );
The constraint where TEvent : Event<TSub>
ensures the relationship between the event and subscription type that you desire. It's also preferrable in my book to an extension method on the class Type
- because that tends to clutter intellisense. Type
is used in many situations, and having spurious methods appear in Intellisense on all instances of Type
tends to be confusing. It's also non-obvious for consumers of library that this is the way to "subscribe" - unless they've actually seen a code example of it.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With