Events and aggregates

[earth]

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.

[Marc Gravell]

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

[Jon Skeet [C# MVP]]

On Jun 2, 12:11 pm, Marc Gravell <[e-mail]:

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

[Marc Gravell]

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

[earth]

On Jun 2, 12:11 pm, Marc Gravell <[e-mail]:

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.

[Marc Gravell]

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

[Jon Skeet [C# MVP]]

On Jun 2, 1:32 pm, Marc Gravell <[e-mail]:

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

[Peter Duniho]

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

[Peter Duniho]

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