471,330 Members | 1,682 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,330 software developers and data experts.

Events and aggregates

If I have a class call it ClassA which is an aggregate of ClassB.

ClassA delegates to ClassB (I mean that in the English sense of the
word not in the C# reserved word sense). So for instance
ClassA.MyMethod calls ClassB.MyMehtod.

ClassA also has an event but the event is actually raised by ClassB.
The event can be called FooRaised.

The handler of the event will be on a third class ClientClass and
ClientClass will call ClassA.FooRaised += FooRaisedHandler.

Now,

I could have and event handler in ClassA that is hooked to the exposed
event of ClassB. When ClassB raises the event the ClassA handler will
raise the event on ClassA and the ClientClass.FooRaisedHandler will be
called.

However I don't want a handler in ClassA to be hooked to the event on
ClassB and effectively pass the event on. I want the handler in
ClientClass to be passed through to the event in ClassB so that when
ClassB raised the event the handler on ClientClass is called directly.

I could do this in other languages because events have accessor
methods where the handler is passed. In the set accessor I would
assign the handler to the aggregated class. In C# it does not appear
that events have accessor methods. This seems like a great big hole.

Is there a way to pass though the handler as I described?

I have considered a method on ClassA that accepts the event handler
type and will assign it to the event in ClassB but it is not really
the right way to expose an event.
Jun 27 '08 #1
8 1121
Yes; you can use explicit event implementation to do exactly this:

public class ClassB {
public event EventHandler SomeEvent;
}
public class Class A {
private readonly ClassB b = new ClassB();

public event EventHandler SomeEvent {
add {b.SomeEvent += value;}
remove {b.SomeEvent -= value;}
}
}

The only problem with this approach is that callers will see the "b"
instanc as the "sender", not the instance of ClassA to which they
subscribed. This can be confusing, and can prevent some binding-sources
(in particular list-based) from correctly identifying the origin of the
event.

Marc
Jun 27 '08 #2
On Jun 2, 12:11 pm, Marc Gravell <marc.grav...@gmail.comwrote:
Yes; you can use explicit event implementation to do exactly this:

public class ClassB {
public event EventHandler SomeEvent;}

public class Class A {
private readonly ClassB b = new ClassB();

public event EventHandler SomeEvent {
add {b.SomeEvent += value;}
remove {b.SomeEvent -= value;}
}

}

The only problem with this approach is that callers will see the "b"
instanc as the "sender", not the instance of ClassA to which they
subscribed. This can be confusing, and can prevent some binding-sources
(in particular list-based) from correctly identifying the origin of the
event.
And of course one answer to that is to make ClassA subscribe (once) to
ClassB's event, and then call its own list of handlers when ClassB's
event is raised, merely changing the sender.

Jon
Jun 27 '08 #3
Yes, but the OP covered that already (at length) stating:
However I don't want a handler in ClassA to be hooked to the event
on ClassB and effectively pass the event on.
Marc
Jun 27 '08 #4
On Jun 2, 12:11 pm, Marc Gravell <marc.grav...@gmail.comwrote:
Yes; you can use explicit event implementation to do exactly this:

public class ClassB {
public event EventHandler SomeEvent;}

public class Class A {
private readonly ClassB b = new ClassB();

public event EventHandler SomeEvent {
add {b.SomeEvent += value;}
remove {b.SomeEvent -= value;}
}

}

The only problem with this approach is that callers will see the "b"
instanc as the "sender", not the instance of ClassA to which they
subscribed. This can be confusing, and can prevent some binding-sources
(in particular list-based) from correctly identifying the origin of the
event.

Marc
Thats great. I could not imagine that something like this would be
missed. When it comes to the sender of the event, in this case class
b has a reference to class a so I can put that in the sender
parameter. Overall I think it is ok to do that because it properly
encapsulates class b.
Jun 27 '08 #5
One other thought - if "b" has a reference to "a", it could equally
simply call an internal OnSomeEvent method on "a", and let "a" host the
event. Either way similar end result.

Marc
Jun 27 '08 #6
On Jun 2, 1:32 pm, Marc Gravell <marc.grav...@gmail.comwrote:
Yes, but the OP covered that already (at length) stating:
Well if you're going to be picky and expect me to start actually
reading the question, I might as well stop posting ;)

Jon
Jun 27 '08 #7
On Mon, 02 Jun 2008 05:32:51 -0700, Marc Gravell <ma**********@gmail.com>
wrote:
Yes, but the OP covered that already (at length) stating:
However I don't want a handler in ClassA to be hooked to the event
on ClassB and effectively pass the event on.
He did write that. But it's not very clear _why_ he wrote that. It would
be helpful if the OP could explain why it is he doesn't just want ClassA
to act as a proxy. That's basically what the delegation of the rest of
the things ClassB does would do anyway. What's so bad about it just
because it's an event being delegated?

Pete
Jun 27 '08 #8
On Mon, 02 Jun 2008 06:08:57 -0700, Marc Gravell <ma**********@gmail.com>
wrote:
One other thought - if "b" has a reference to "a", it could equally
simply call an internal OnSomeEvent method on "a", and let "a" host the
event. Either way similar end result.
Indeed. I think it's a little odd that ClassB "knows" about ClassA anyway
(it makes the whole delegation thing a little awkward), but IMHO given
that it does I'd say that having ClassB just tell ClassA to raise the
event (as Marc suggests) is a better approach than having ClassB
impersonate ClassA.

Pete
Jun 27 '08 #9

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

14 posts views Thread by JPRoot | last post: by
12 posts views Thread by jao | last post: by
1 post views Thread by swethak | last post: by
reply views Thread by rosydwin | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.