EventArgs

  • Thread starter Thread starter GiJeet
  • Start date Start date
G

GiJeet

Hello, just wondering, in the event model windows uses, they use an
argument wrapper class called EventArgs which you can subclass to
encapsulate all the arguments you need to pass to any eventhandler
method, so my question is, why is this model not used for pass
arguments to ALL methods? Why pass many individually typed arguments
to methods? Why not create our own MethodArgs class and wrap any
argument the method requires, this way we are only passing ONE
argument to methods - our class with any member we need to send to the
method.

And the method could just as easily return a MethodArgs class to pass
back any variables we need to manipulate.

It just seems so much more cleaner and MS is doing it with their event
model...

G
 
Hello, just wondering, in the event model windows uses, they use an
argument wrapper class called EventArgs which you can subclass to
encapsulate all the arguments you need to pass to any eventhandler
method, so my question is, why is this model not used for pass
arguments to ALL methods? Why pass many individually typed arguments
to methods? Why not create our own MethodArgs class and wrap any
argument the method requires, this way we are only passing ONE
argument to methods - our class with any member we need to send to the
method.

And the method could just as easily return a MethodArgs class to pass
back any variables we need to manipulate.

It just seems so much more cleaner and MS is doing it with their event
model...
Click to expand...

What your describing is not unheard of. I personally try to keep
methods to 3 or less arguments. When it extends beyond that, I start to
wonder if there is a way to simplify.
 
One reason NOT to do this is because with overloaded methods...its easier to
"see" what you actually need to use the method.
THe eventarg method would have "optional" properties. Which would make
things harder.
..

However, I use a variation of this idea with my wcf and when I need to
update the database.
I create a "arg" class, which contains the BARE MINIMUM amount of data that
I need to ship into for an update (or insert).

public class EmployeeUpdateArg
Guid EmpUUID
string LastName
string FirstName


the reason I do this is so that I am shipping "across the wire" the smallest
serializable class I can.
And maintainence is easier (as you suggest yourself).
I don't change the argument list to the method(s), I just add a new property
to the Arg class.

AND I already have a defined class, in case (in the future) I become
interested in that event happening.
I don't have to retro fit a MySubClass : EventArg class.

So I see your point. And I think you're free to incorporate that mentality
as you'd like.

...

But as far as a default for MS to do:
Like I said, the top thing I mention is enough not to do it. I like seeing
a list of a few parameters about what is available for me to use (method)
and what HAS to go in for a particuliar overload.
I don't want to wire an "arg" class, and then try it, and then it tell me
"Since you sent in an A object, you can't send in a B object, but you need
to send in a C object".
Boo to that.

...

Optional parameters in VB6 where always a headache. It starts out with good
intentions, and before long, its tough to remember what has to and what
doesn't have to go in.

...
 
Hello, just wondering, in the event model windows uses, they use an
argument wrapper class called EventArgs which you can subclass to
encapsulate all the arguments you need to pass to any eventhandler
method, so my question is, why is this model not used for pass
arguments to ALL methods? Why pass many individually typed arguments
to methods?  Why not create our own MethodArgs class and wrap any
argument the method requires, this way we are only passing ONE
argument to methods - our class with any member we need to send to the
method.

And the method could just as easily return a MethodArgs class to pass
back any variables we need to manipulate.

It just seems so much more cleaner and MS is doing it with their event
model...

G
Click to expand...

Hi,

I cannot imagine myself creating one type per each set of parameters I
need.
 
I cannot imagine myself creating one type per each set of
parameters I need.
Why? What do you mean by this?

I can see the overhead for simple methods that only take one or two
parameters but I've seen methods with a dozen or so parameters and
it's a pain to keep them all straight when some get changed or removed
so there has to be a better way.
 
Well, why not go the other way? Given that so many .NET events have
either no data at all, or just one interesting item, why force all of the
events to use an EventArgs-derived parameter? Why not allow events to
expose simpler signatures where appropriate?

Here's what I think:

As far as the .NET event model goes, there's some minor benefits to have a
standardized pattern to follow when writing events and their handlers. I
don't even follow this pattern 100% in my own events, but I usually do.
For me, it means that when I'm writing an event handler, if I know the
name of the event, I now know everything I need to about the handler and
the arguments it takes, with very few exceptions.
Click to expand...

Indeed, before C# 2 I don't think there were many benefits at all to
following the pattern. However, with C# 2's delegate covariance/
contravariance, you can use a more general event handler delegate to
subscribe to a more specific one - e.g. a method with a normal
EventHandler signature can be used for a KeyPressEventHandler etc.
Frankly I don't expect that to be used *very* often, and I'm still
somewhat leery of the EventHandler pattern in general, but at least
it's got *some* benefit now :)

Jon
 
GiJeet said:
parameters I need.
Why? What do you mean by this?

I can see the overhead for simple methods that only take one or two
parameters but I've seen methods with a dozen or so parameters and
it's a pain to keep them all straight when some get changed or removed
so there has to be a better way.
Click to expand...

Frequently I find that cases where a method takes a ridiculous number of
parameters it's generally because you're passing in a lot of data that relates
to a logical item, and you'd be better off passing in a business object. I've
really only run into that in circumstances where a developer refused to use
business objects for any reason (why is beyond me), and most of the time it's
unnecessary.

In the few circumstances where legitimately there are 17 *different* things a
method needs to examine/manipulate, then so be it, the method should accept 17
different parameters.

Chris.
 
In the few circumstances where legitimately there are 17 *different* things a
method needs to examine/manipulate, then so be it, the method should accept 17
different parameters.

Chris.
Click to expand...

Yikes!! This becomes a maintenance nightmare when things change -
keeping all the parameters aligned. In a situation like this, why not
wrap them all up in a class or struct or dictionary object? Again, MS
does it with EventArgs.

G
 
GiJeet said:
Yikes!! This becomes a maintenance nightmare when things change -
keeping all the parameters aligned. In a situation like this, why not
wrap them all up in a class or struct or dictionary object? Again, MS
does it with EventArgs.
Click to expand...

If it changes, why not simply overload the method?
To my mind, that is far simpler, and far clearer than creating a new object to
send through.

Consider that in a lot of cases, what you're advocating would actually create
more code than simply having a method accept all the parameters:
SomeMethod(new SomeMethodArgs(methodArg1, methodArg2, ..., methodArg17));

Also, looking to EventArgs, it's an object sent to an interface used throughout
the framework. If you are talking about developing such an interface for an
application, it may be desirable to build that in. I just haven't found a real
use for it.


Chris.
 
GiJeet said:
Yikes!! This becomes a maintenance nightmare when things change -
keeping all the parameters aligned. In a situation like this, why not
wrap them all up in a class or struct or dictionary object? Again, MS
does it with EventArgs.

G
Click to expand...

How would you populate your class?

If you propose that this:

obj.Method(1, "a", 'x', true, false, 42, 73, 10.0f, new Object());

should be replaced with this:

obj.Method(new Arg(1, "a", 'x', true, false, 42, 73, 10.0f, new Object()));

then there isn't much use for it.

On the other hand, would you like this?

Arg a = new Arg();
a.ItemCount = 1;
a.SomeLetter = "a";
a.SomeChar = 'x';
a.IsValid = true;
a.IsNotValid = false;
a.Adams = 42;
a.Age = 73;
a.SalaryK = 10.0f;
a.LockObject = new Object();
obj.Method(a);

then ... yikes is the word indeed.

One of the reasons for the EventArgs way is to handle future changes
without breaking any code, new arguments to the events could be passed
silently without the need for a change to the code handling the events.
 
 > I cannot imagine myself creating one type per each set of
parameters I need.
Why?  What do you mean by this?

I can see the overhead for simple methods that only take one or two
parameters but I've seen methods with a dozen or so parameters and
it's a pain to keep them all straight when some get changed or removed
so there has to be a better way.
Click to expand...

The overhead of creating one type per method call would be daunting
 
Frequently I find that cases where a method takes a ridiculous number of
parameters it's generally because you're passing in a lot of data that relates
to a logical item, and you'd be better off passing in a business object. I've
really only run into that in circumstances where a developer refused to use
business objects for any reason (why is beyond me), and most of the time it's
unnecessary.

In the few circumstances where legitimately there are 17 *different* things a
method needs to examine/manipulate, then so be it, the method should accept 17
different parameters.
Click to expand...

I agree with you, sometimes you really need all those values.
Especially in constructors.
One of the constructor for SqlParameter takes 13 parameters :)
 
Well. To be honest the framework uses both approaches. See

Process.Start("IExplore.exe","www.northwindtraders.com") vs

ProcessStartInfo startInfo= new ProcessStartInfo("IExplore.exe");
startinfo.WindowStyle= blah blah
startinfo.Arguments= blah blah
ProcessStart(startInfo);

Regards,
Jeff
 
Back
Top