Interfaces and Events

[goodoldave]

Hey everyone, I need some advice concerning Interfaces and delegates.

I would like to define a delegate inside of an interface (I know a
delegate is a class but hear me out)


Here is a sample:

Interface A

Class B inherits Interface A

Program C creates an instance of Class B and needs to consume events
from Class B.

I would like for Class B to be required to implement the delegates via
Interface A. Is this possible? Is this proper? Can/Should I use an
abstract class for this? Is there a better way?

 

[William Stacey [MVP]]

Sounds like a pipeline. Instead of using delegates and events, I would use
message passing. Each class will expose a bounded queue (blocking style)
and have a worker thread (or a user TP) block on messages and handle them as
needed.

--
William Stacey [MVP]

| Hey everyone, I need some advice concerning Interfaces and delegates.
|
| I would like to define a delegate inside of an interface (I know a
| delegate is a class but hear me out)
|
|
| Here is a sample:
|
| Interface A
|
| Class B inherits Interface A
|
| Program C creates an instance of Class B and needs to consume events
| from Class B.
|
| I would like for Class B to be required to implement the delegates via
| Interface A. Is this possible? Is this proper? Can/Should I use an
| abstract class for this? Is there a better way?
|

 

[Bob Jones]

William,

Thank you for that. It's a shame I have no idea how to implement what you
are speaking of. Can you point me (and others reading this) in the right
direction?

Regards..

 

[Jon Skeet [C# MVP]]

Hey everyone, I need some advice concerning Interfaces and delegates.

I would like to define a delegate inside of an interface (I know a
delegate is a class but hear me out)


Here is a sample:

Interface A

Class B inherits Interface A

Program C creates an instance of Class B and needs to consume events
from Class B.

I would like for Class B to be required to implement the delegates via
Interface A. Is this possible? Is this proper? Can/Should I use an
abstract class for this? Is there a better way?

You can certainly include events (not delegates) within interfaces.
It's not terribly common, but it makes sense in certain situations.

 

[Bob Jones]

Jon,

That's how I originally set the interface up. However, I found that I could
not figure out how Program C was supposed to cosume those events. The events
are raised by Class B and need to be consumed by Program C.

My understanding is that Class B need to implement the delegates and Program
C should consume those events. How can I make this situation work?

Regards

 

[William Stacey [MVP]]

If this will be a one-off and one or two classes, I don't want to send you
off on into a mess. But if you will be doing a lot of this in your app, it
is a pattern that can bear a lot of fruit and simplify things. For some
background, check out
http://www.eecs.harvard.edu/~mdw/papers/seda-sosp01.pdf
It is server focused, but the same idea is great for client side and UI
update processing as well. Some nice things are: message based, not method
based so it is easy to refactor code and is loosely coupled. It is
naturally pluggable for easy adding and changing Stages, even at runtime.
Each stage can send messages back to itself or any other stage. Shutdown
processing is as easy as sending a stop message which gets sent along your
Stages (this can sometimes be one of the harder issues to handle cleanly
with other patterns). You can throttle and manage speed at each stage as
you have the queue as the focus point. Many others. First, you will need a
bounded-blocking thread safe queue. Here is mine that also have some
examples using pipes and queues and thread pools.
http://channel9.msdn.com/ShowPost.aspx?PostID=161030 I am actually working
on a server using this "SEDA" pattern and seems to make a lot of sense so
far and seems to be clean. I will try to work up something simple and put
in the C9 Sandbox.

--
William Stacey [MVP]

| William,
|
| Thank you for that. It's a shame I have no idea how to implement what you
| are speaking of. Can you point me (and others reading this) in the right
| direction?
|
| Regards..
|
|
| | > Sounds like a pipeline. Instead of using delegates and events, I would
| > use
| > message passing. Each class will expose a bounded queue (blocking
style)
| > and have a worker thread (or a user TP) block on messages and handle
them
| > as
| > needed.
| >
| > --
| > William Stacey [MVP]
| >
| > | > | Hey everyone, I need some advice concerning Interfaces and delegates.
| > |
| > | I would like to define a delegate inside of an interface (I know a
| > | delegate is a class but hear me out)
| > |
| > |
| > | Here is a sample:
| > |
| > | Interface A
| > |
| > | Class B inherits Interface A
| > |
| > | Program C creates an instance of Class B and needs to consume events
| > | from Class B.
| > |
| > | I would like for Class B to be required to implement the delegates via
| > | Interface A. Is this possible? Is this proper? Can/Should I use an
| > | abstract class for this? Is there a better way?
| > |
| >
| >
|
|

 

[Pete Davis]

You can certainly include events (not delegates) within interfaces.
It's not terribly common, but it makes sense in certain situations.

Really? It's not common? I do it all the time. Is there some reason it's not
common?

To give you an example, for most of my larger apps, I have generally create
some sort of plugin framework (I'm still trying to come up with a good,
reusable plugin framework, but can't seem to accomplish this). Normally,
I'll create interfaces which are implemented in the main app, usually
something like an IApplication interface. Then I'll have events that get
triggered for things such as initialization completing, app shutting down,
windows opening or closing, or whatever.

This is simply an example. I could think of tons of others. I could
implement these as methods in the plugins and have the main app call those
methods when these events take place, but then every plugin would have to
implement the methods.

Anyway, just curious if there's something wrong with having events in
interfaces or you just don't see it very commonly.

Pete

 

[Pete Davis]

It might look something like this:


namespace MyInterface
{
public delegate void MyEventHandler(object sender, MyEventArgs e);

interface InterfaceA
{
....

event MyEventHandler MyEvent;

}
}


namespace MyImplementation
{
using MyInterface;

public class ClassB : InterfaceA
{

...

protected virtual OnMyEvent(MyEventArgs e)
{
if (MyEvent != null)
{
MyEvent(this, e);
}
}
...

public event MyEventHandler MyEvent;
}
}

Calling OnMyEvent triggers MyEvent.

Then your program could have something like this somewhere:

public void AMethod()
{
ClassB myClassBOb = new ClassB();
myClassBOb.MyEvent += new MyEventHandler(ClassBMyEvent)
}

private void ClassBMyEvent(object sender, MyEventArgs e)
{
[do something here]
}


Hope that makes sense.

Pete

Jon,

That's how I originally set the interface up. However, I found that I
could not figure out how Program C was supposed to cosume those events.
The events are raised by Class B and need to be consumed by Program C.

My understanding is that Class B need to implement the delegates and
Program C should consume those events. How can I make this situation work?

Regards

 

[Bob Jones]

Andy,

Almost! The only difference between your code and what I am trying to
accomplish is that I want the program to receive (consume) the event, not
fire the event. The event should get fired in class Lulli.

Regards

Jon,

That's how I originally set the interface up. However, I found that I
could not figure out how Program C was supposed to cosume those events.
The events are raised by Class B and need to be consumed by Program C.

My understanding is that Class B need to implement the delegates and
Program C should consume those events. How can I make this situation
work?

Regards

<snip />

Not sure if this is what you are looking for:

namespace ConsoleApplication14
{
delegate void FooHandler();

interface IXox
{
event FooHandler Foo;
}

class Lulli : IXox
{
public event FooHandler Foo;

public void OnFoo()
{
if (Foo != null)
Foo();
}
}

class Program
{
static void Main(string[] args)
{
IXox xox = new Lulli();
xox.Foo += new FooHandler(xox_Foo);

// Demo: Raise the event!
((Lulli)xox).OnFoo();
}

static void xox_Foo()
{
Console.WriteLine("Foo called.");
}
}
}

Or do you mean the C is really another different programm? Then you have
to do some sort of IPC, e.g. remoting.

HTH,
Andy

 

[Andy]

Jon,

That's how I originally set the interface up. However, I found that I could
not figure out how Program C was supposed to cosume those events. The events
are raised by Class B and need to be consumed by Program C.

My understanding is that Class B need to implement the delegates and Program
C should consume those events. How can I make this situation work?

Regards

<snip />

Not sure if this is what you are looking for:

namespace ConsoleApplication14
{
delegate void FooHandler();

interface IXox
{
event FooHandler Foo;
}

class Lulli : IXox
{
public event FooHandler Foo;

public void OnFoo()
{
if (Foo != null)
Foo();
}
}

class Program
{
static void Main(string[] args)
{
IXox xox = new Lulli();
xox.Foo += new FooHandler(xox_Foo);

// Demo: Raise the event!
((Lulli)xox).OnFoo();
}

static void xox_Foo()
{
Console.WriteLine("Foo called.");
}
}
}

Or do you mean the C is really another different programm? Then you have
to do some sort of IPC, e.g. remoting.

HTH,
Andy

 

[William Stacey [MVP]]

That SEDA pattern I posted above seems like it would make for a nice plugin
pattern as well. Think all the plugin needs is the expected Message type.
Think either interface or abstract class would work, but have not run that
around yet.

--
William Stacey [MVP]

|
| | >
| > You can certainly include events (not delegates) within interfaces.
| > It's not terribly common, but it makes sense in certain situations.
| >
|
| Really? It's not common? I do it all the time. Is there some reason it's
not
| common?
|
| To give you an example, for most of my larger apps, I have generally
create
| some sort of plugin framework (I'm still trying to come up with a good,
| reusable plugin framework, but can't seem to accomplish this). Normally,
| I'll create interfaces which are implemented in the main app, usually
| something like an IApplication interface. Then I'll have events that get
| triggered for things such as initialization completing, app shutting down,
| windows opening or closing, or whatever.
|
| This is simply an example. I could think of tons of others. I could
| implement these as methods in the plugins and have the main app call those
| methods when these events take place, but then every plugin would have to
| implement the methods.
|
| Anyway, just curious if there's something wrong with having events in
| interfaces or you just don't see it very commonly.
|
| Pete
|
|

 

[Pete Davis]

The event IS being fired in class Lulli. It's getting fired in the OnFoo()
method where if (Foo != null) Foo();

Foo is the event. the statement 'Foo();' triggers it.

Pete

Andy,

Almost! The only difference between your code and what I am trying to
accomplish is that I want the program to receive (consume) the event, not
fire the event. The event should get fired in class Lulli.

Regards

Jon,

That's how I originally set the interface up. However, I found that I
could not figure out how Program C was supposed to cosume those events.
The events are raised by Class B and need to be consumed by Program C.

My understanding is that Class B need to implement the delegates and
Program C should consume those events. How can I make this situation
work?

Regards

<snip />

Not sure if this is what you are looking for:

namespace ConsoleApplication14
{
delegate void FooHandler();

interface IXox
{
event FooHandler Foo;
}

class Lulli : IXox
{
public event FooHandler Foo;

public void OnFoo()
{
if (Foo != null)
Foo();
}
}

class Program
{
static void Main(string[] args)
{
IXox xox = new Lulli();
xox.Foo += new FooHandler(xox_Foo);

// Demo: Raise the event!
((Lulli)xox).OnFoo();
}

static void xox_Foo()
{
Console.WriteLine("Foo called.");
}
}
}

Or do you mean the C is really another different programm? Then you have
to do some sort of IPC, e.g. remoting.

HTH,
Andy

 

[Jon Skeet [C# MVP]]

That's how I originally set the interface up. However, I found that I could
not figure out how Program C was supposed to cosume those events. The events
are raised by Class B and need to be consumed by Program C.

My understanding is that Class B need to implement the delegates and Program
C should consume those events. How can I make this situation work?

Other way round - if program C is meant to *consume* those events, then
it needs to subscribe to the events with event handlers which implement
the delegates.

 

[Jon Skeet [C# MVP]]

Really? It's not common? I do it all the time. Is there some reason it's not
common?

Not particularly - it's just not something I see that often.

To give you an example, for most of my larger apps, I have generally create
some sort of plugin framework (I'm still trying to come up with a good,
reusable plugin framework, but can't seem to accomplish this). Normally,
I'll create interfaces which are implemented in the main app, usually
something like an IApplication interface. Then I'll have events that get
triggered for things such as initialization completing, app shutting down,
windows opening or closing, or whatever.

Those all seem like perfectly good examples. There's nothing wrong with
them at all - it's just not that common. For instance, I don't think
there are very many interfaces in the framework that specify events.

(Of course, now I'll find there are hundreds...)