Empty Type Parameters


The aggregated Event and DelegateCommand from the Composite Application Guidance (aka Prism) require a type specification for their parameter or payload. This is sometimes unnecessary when no information is published, such as raising an event to indicate that something has finished loading. One approach is to simply specify object as the type parameter and use null as the value.

public class RecordsLoadedEvent : CompositePresentationEvent<object> {}
_eventAggregator
	.GetEvent<recordsloadedevent>()
	.Publish(null);

However, I’m a big believer of making your intentions obvious using code. Specifying an object as the parameter hardly makes it clear that it’s not used. Any other developer using it would have to dig through the code to check that the object supplied doesn’t have any significance.

We see another instance of this problem in the .NET Framework itself. By convention every event is fired with a sender and an argument. The event argument is often not used and instead of publishing null, the framework provides an Empty value – EventArgs.Empty.

Generalising that idea, we can create an Empty type with a constant value.

public class Empty
{
	private static readonly Empty _value = new Empty();
	
	public static Empty Value
	{
		get { return _value; }
	}
	
	private Empty()
	{
	}
}

Using this for our aggregated events and commands now makes it obnoxiously clear to consumers that it’s not being used.

public class RecordsLoadedEvent : CompositePresentationEvent<empty> {}
_eventAggregator
	.GetEvent<recordsloadedevent>()
	.Publish(Empty.Value);
Advertisements

9 thoughts on “Empty Type Parameters

    1. my first comment not appear will

      if i want to use more than one Arg
      like CompositePresentationEvent
      do you have any idea to do such action?

      i mean :
      CompositePresentationEvent

      1. Maybe I’m misunderstanding you, but can’t you just create your own class?

        public class MyEventArg
        {
        	public string Name { get; set; }
        	public int Number { get; set; }
        }
        
        public class MyEvent : CompositePresentationEvent<MyEventArg> {}
        
        _eventAggregator.GetEvent<MyEvent>().Publish(new MyEventArg
        {
        	Name = "Ahmed",
        	Number = 42
        });
        
  1. However, I’m a big believer of making your intentions obvious using code. Specifying an object as the parameter hardly makes it clear that it’s not used. Any other developer using it would have to dig through the code to check that the object supplied doesn’t have any significance.

    I agree wholeheartedly with this line of thinking. Thanks for the sound advice. I’ve implemented this same practice.

  2. I like this idea, but the problem with it is that then you have to push a reference to the Empty class around to all your projects…

  3. @Stephen: Sure. But if you’re using a common infrastructure class library to hold your interfaces and PubSubEvents and any other things that are needed in multiple modules, most if not all of your modules are going to already be referencing that project.

    And kudos to the author for a great solution.

    Though I am curious as to why the private data member rather than just returning “new Empty()” from the property directly? Sure, you’ll have a little extra overhead in that you’ll be creating a new object each time rather than creating only one at startup, but I can’t see it being that much of a drain, and it cleans up the code somewhat.

  4. @GrantA wow, this was from a while back. Thanks. As for the private data member vs `new Empty`, I think I was just copying the pattern used by EventArgs.Empty and a bit because there’s no real significant to differences instances of Empty. But yeah, not a drain either way.

  5. You’re welcome. I’m actually doing my first project in Prism, and ran into a case where a few modules can result in the application needing to exit. So I figured having a PubSubEvent (CompositePresentationEvent pre-Prism version 5.0) to indicate that it’s time to exit would be a good way to do this. But it doesn’t need an argument, obviously. So I have “public class ExitEvent : PubSubEvent” which works well. The view model of Shell subscribes to the event and handles closing of the applicatio when the event is published by any module. It’s interesting, though, that even as of the current version of Prism (v6.1) there still isn’t a built in empty argument type for PubSubEvents.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s