title: C# simple Event Raising - using "sender" vs. custom EventArgs
body: <p>Consider this scenario.  I have an object, lets call it.... Foo.  Foo raises a simple event named "Loaded".  As part of the information for the event, consumers will need to know which foo object raised the event.  Our team has adopted the following pattern.</p>
  
  <p>1)  Create a new class that inherits from EventArgs - for example,
      FooEventArgs : System.EventArgs.</p>
  
  <p>2)  Add a property of type Foo to the FooEventArgs, which is set by being passed in via the constructor.</p>
  
  <p>3)  Declare the event using the generic version of EventHandler, so</p>
  
  <pre><code>public event EventHandler&lt;FooEventArgs&gt; Loaded;
  </code></pre>
  
  <p>4)  Raise the event from the Foo class with the following signature:</p>
  
  <pre><code>Loaded(this, new FooEventArgs(this));
  </code></pre>
  
  <p>Essentially what this does is makes the "sender" the foo object, but it <em>also</em> puts the foo object reference into the event argument as a strongly typed property.  </p>
  
  <p>One advantage for doing this is that no one has to bother with casting "sender" when they handle the event, which lowers the coupling between the event consumer and the event raiser.  Another "advantage" is that if the type of the event raiser ever has to change, and hence the strongly typed property (which hopefully never happens), then instead of simply having code start to fail on the cast when it comes out as null, the API actually breaks so it can be fixed at compile time.</p>
  
  <p>To me, this pattern seems like it might be overkill.  Should they be trusting the "sender" parameter more, and ditching the custom event arguments?  My team argues that no one really uses the sender parameter.  What's the best practice for passing out a reference to the event-raising object?</p>
  
  <p><strong>EDIT:  Great feedback so far, I'll leave this open for another day or so before I accept one.</strong></p>