views:

262

answers:

3

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) => e.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);
}
+3  A: 

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.

LBushkin
Thanks for your answer! I realize that the constraint can be enforce in this way (see above edit). Your suggestion is close to one that I considered, but preferred the extension method. I understand the aversion to using extension methods on a class like Type, but the method is localized to a single class which handles the subscriptions. Also, it isn't a library method that would be consumed by others.
Bryan Matthews
A: 

You can probably get close extending System.Type (to have typeof(T).) and adding an (extension) method to context that transforms a .NET type to your internal type representation (same as returned by GetGraphType).

static class Ext {

    public static TypeofTypeofBar GetGraphTypeFromDotNetType(this Context ctx, Type t) {
       return __something(t);
    }

    public static void SubscribeTo<F, E>(this Type type, Context ctx, E e)
        where E: Event<T> {
        context.GetGraphTypeFromDotNetType(type).Subscribe<F>(a);
    }

}

...

typeof(Bar).SubscribeTo(context, action);
Mau
Hey Mau, just so happens the method you described already exists. I am a bit confused about the type parameters in your example. Did you mean "where E : Event<F>"? If that was the case I would not need to pass an "event" argument, the type would suffice (in fact I would not be able to provide an event instance). However, it seems like the type of the subscriber would still have to be supplied as a type parameter. So, you would basically end up with "typeof(Bar).SubscribeTo<Bar, Fizz>(ctx)", which is yet another variation that I am not thrilled about. Thanks for the suggestion though!
Bryan Matthews
+1  A: 

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
    }
}
dss539
This is exactly what I was looking for. It allows me to accomplish my original goal of readability, without bypassing the compiler. Thanks!
Bryan Matthews
@Bryan - glad I could help :)
dss539