Overloading event parameters

Well, it's been a long time, but I'm back...

Obviously, I've done a lot of searching and experimenting but I'm having no luck. I have a workaround, but it's ugly, and I HATE ugly code :)

Problem is, I am using events to expose functionality, but I want to be able to overload the parameters that can be used when raising said events.

i.e. I want developers using this functionality to be able to call the functionality in different ways:
RaiseEvent(string, int, int);
RasieEvent(xmldocument, int, int);
etc, etc.

I've come up with two ways around my problem:
1. Expose the events through an overloaded static methods, and then raise specific events that way (i.e. RaiseEvent1, RaiseEvent2)
2. Pass in a "EventParameters" style object.

The first is ugly. The second will not be liked by my boss - he's stressed consistently that the interface to this functionality should be as simple as possible, and even adding "new EventParameters()" will draw his ire.

To show what I want with code, basically I want to be able to go

Code:

---

private delegate void MyEventDelegate(String str, int num, int pos);
private delegate void MyEventDelegate(XmlDocument doc, int num, int pos);
public static event MyEventDelegate RaiseEvent;

---

Obviously that syntax won't work, but I hope it expresses what I mean. And yes, I understand that multiple handlers, etc would need to be coded.

Is it possible to overload events? It doesn't seem to be, but no harm in asking :)

edit: VS2005 btw. .Net 2.0

I think that number 2 is the only way to go. Overload the constructor for the different signatures and let the method which raises the event sort it out. If your boss doesn't like that, I don't know how you can get much simpler...

Quote:

---

Originally Posted by BigEd781

If your boss doesn't like that, I don't know how you can get much simpler...

---

hehe - I hear ya. I know him though. Smart guy, but he has beliefs on what he thinks is "right". I actually agree with him on this one though - creating a new object instance seems like it SHOULD be redundant. I know it's not much, but... :)

Creating the instance of EventParameters can be "ecapsulated" in each of everloaded RaiseEvent method. And I thing that it is the right way to have two types of EventParameters, one carrying String and one carrying XmlDocument.

Only other way I can imagine is to declare the delegate like:

Code:

---

private delegate void MyEventDelegate(object obj, int num, int pos);

---

OR

You can avoid using events and implement some kind of observer pattern and just invoke the appropriate overloaded method on the registered interface implementation.

It is C#, it needs to be used in OOP way ;-)

Thanks for the input Boudino.

The first suggestion seems similar to my "option 1" above. It's OK, but when I'm looking at a few overloads, it get's ugly.

The second object would work, but I'm opposed to it. It makes it too easy for the developer using the class to provide stuff the class can't handle.

I don't think an observer pattern is appropriate for my current requirements, although as I've kept the specifics under wraps, I appreciate the thought.

Seems it can't be done - that's not a problem. Would be nice, but my solution is still lean and easy to understand/use without it :)

Quote:

---

Originally Posted by Zeb

Problem is, I am using events to expose functionality, but I want to be able to overload the parameters that can be used when raising said events.

---

So use EventHandler<T>!

Code:

---


public event EventHandler <MyEventArgs> MyEvent;

public class MyEventArgs : EventArgs
{
    public int Num { get; set; }
    public int Position { get; set; }
}

public class StringMyEventArgs : MyEventArgs
{
    public string Data { get; set; } 
}

public class XmlMyEventArgs : MyEventArgs
{
    public XmlDocument Xml { get; set; }
}

---

Your event can be passed any EventArg class deriving from MyEventArgs (as i declared it to be an event of that type), so you just subclass that to put in any special data. Would that be a good solution for your problem?

Whatever you choose, if you should still consider using the EventHandler method above rather than defining custom delegates. The EventArgs pattern is a very nice pattern and makes events easily extensible without having to change the method signature. This is great when you want to add one more parameter but don't want to modify the 100 places where the event is used ;)

It's closer. Still need to instantiate an "EventArgs" object, so it's almost the same as "option 2". Almost - the only real difference being the declaration of the event itself where it (seems) to just use a generic delegate instead of an explicitly declared one. Correct me if I'm wrong here :)

Quote:

---

the only real difference being the declaration of the event itself where it (seems) to just use a generic delegate instead of an explicitly declared one

---

There are two differences. That's the first and biggest one. The second one is that this uses the standard pattern for creating events, which neither of your current options do ;)

If you're worried about design patterns/maintainability, then you really should go with the EventArgs method. That's the standard way to use events. If I saw anyone creating .NET events without using the standard EventHandler (or EventHandler<T>) form, I'd definitely be having words with them ;)

Quote:

---

Originally Posted by Mutant_Fruit

If I saw anyone creating .NET events without using the standard EventHandler (or EventHandler<T>) form, I'd definitely be having words with them ;)

---

A worthy point! A compelling argument and you have sold me :)