Virtual functions vs event handlers
Author
Hi,
I figure that virtual functions and event handlers are quite similar.
They are both basically functions called through a function pointer and thus enable you to vary the code that gets executed whilst the system that is calling the function remains unchanged.
So, when designing a class, how do I know whether to make a function virtual or just declare an event?
In the former, I need to derive a new class in order to vary the code that gets run, where as in the latter, I need to plug a function into the class instance?
Cheers,
BD.
[edited by - barn door on February 8, 2004 7:53:33 PM]
No they aren''t. Do you come from a Java background? I see Java programmers saying this with regard to C#, but IMO its because their language doesn''t make a distinction. Perhaps conceptually they are similar, but mistaking one for the other muddles your intent. I can''t see how an event handler has a relationship such as "is a" with the base class.
Once you work with events like .NET has them you start to love them more and more. Using virtual functions to simulate events is hacky and tedious at best. In my mind, an event says, "something has happened; I need to react to it but I don''t have all the context I need [in the class firing the event] to process it."
Once you work with events like .NET has them you start to love them more and more. Using virtual functions to simulate events is hacky and tedious at best. In my mind, an event says, "something has happened; I need to react to it but I don''t have all the context I need [in the class firing the event] to process it."
Author
Hey there. No, I don''t come from Java. I just like to break things down from the high level ''is a'' type concepts. And doing this has led me to the conclusion that a virtual function and an event handler are both code called through a function pointer.
This is exactly my point. How does one know when to use one or the other?
quote:Perhaps conceptually they are similar, but mistaking one for the other muddles your intent.
This is exactly my point. How does one know when to use one or the other?
Virtual functions know how to process themselves and the derived class typically has an "is a" relationship with the base class.
An event handler may have no relation to the class firing the event other than mere aggregation.
An event handler may have no relation to the class firing the event other than mere aggregation.
In C++ (I think that''s what you are working with, right?) distinction between virtual functions and events is very big.
(oh, and please specify what you mean by event handlers, are they pointers to functions that you call when sth happens?)
1. Virtual functions are connected to inheritance, events aren''t.
2. Virtual functions have sense of object for that they are called, events -> nope, they are simple functions (hovewer, you can pass ''this'' to handler)
3. Use virtual functions when you have some kind of hierarchy ie.
Entity <-- Monster <-- Orc, Goblin, Human, Dwarf etc.
Now, in Entity class you declare:
virtual void foo(int xxx);
And in each of class Orc, Goblin (and so on) you define this function as:
void foo(int xxx)
{
// do sth specific to this class
}
Then, in the runtime, when you have pointer to Entity, you can assign to it object of class Goblin and when you write pPtr->foo(123) then called will be foo method from class Goblin. When you will call it for member of class Orc then Orc specific method will be called etc. It''s called polymorphism and it''s a wonderful thing, really
Events dont have this beheaviour, they''re simple functions.
(oh, and please specify what you mean by event handlers, are they pointers to functions that you call when sth happens?)
1. Virtual functions are connected to inheritance, events aren''t.
2. Virtual functions have sense of object for that they are called, events -> nope, they are simple functions (hovewer, you can pass ''this'' to handler)
3. Use virtual functions when you have some kind of hierarchy ie.
Entity <-- Monster <-- Orc, Goblin, Human, Dwarf etc.
Now, in Entity class you declare:
virtual void foo(int xxx);
And in each of class Orc, Goblin (and so on) you define this function as:
void foo(int xxx)
{
// do sth specific to this class
}
Then, in the runtime, when you have pointer to Entity, you can assign to it object of class Goblin and when you write pPtr->foo(123) then called will be foo method from class Goblin. When you will call it for member of class Orc then Orc specific method will be called etc. It''s called polymorphism and it''s a wonderful thing, really
Events dont have this beheaviour, they''re simple functions.
Author
I'm coming from .net.
When talking about event handlers, I mean that a function gets called through a function pointer and whatever the pointer is pointing at, if anything, that's what gets run. Furthermore you can change what the function pointer points to.
So I suppose that the event is the function pointer and the event handler is a function that the pointer points to.
Well they can have this behaviour quite easily. If I assign an event 'fooEvent' to class Entity then I can have objects behave differently when the event is raised by plugging in different event handlers.
In fact, one might say this is more flexible than virtual functions because every single instance of Entity can have its own version of foo regardless of its place in the inheritance hierarchy.
If I felt that every instance of a particular class, say Goblin, should always have the same version of foo, say version '6', then I could assign version 6 of foo to the event in the declaration of Goblin. Thus, upon instantiation, Goblin instances would automatically have verison 6 of foo assigned to the 'fooEvent'.
BD.
[edited by - barn door on February 9, 2004 9:58:47 AM]
When talking about event handlers, I mean that a function gets called through a function pointer and whatever the pointer is pointing at, if anything, that's what gets run. Furthermore you can change what the function pointer points to.
So I suppose that the event is the function pointer and the event handler is a function that the pointer points to.
quote:Events dont have this beheaviour, they're simple functions.
Well they can have this behaviour quite easily. If I assign an event 'fooEvent' to class Entity then I can have objects behave differently when the event is raised by plugging in different event handlers.
In fact, one might say this is more flexible than virtual functions because every single instance of Entity can have its own version of foo regardless of its place in the inheritance hierarchy.
If I felt that every instance of a particular class, say Goblin, should always have the same version of foo, say version '6', then I could assign version 6 of foo to the event in the declaration of Goblin. Thus, upon instantiation, Goblin instances would automatically have verison 6 of foo assigned to the 'fooEvent'.
BD.
[edited by - barn door on February 9, 2004 9:58:47 AM]
Author
OK, well I figure that a difference between what I just proposed and virtual functions is that with virtual functions the derived class can override what the base class does completely.
However, if a base class had a default event handler and a derived class also added a handler, when the event was raised, they'd both get called.
[edited by - barn door on February 9, 2004 10:07:58 AM]
However, if a base class had a default event handler and a derived class also added a handler, when the event was raised, they'd both get called.
[edited by - barn door on February 9, 2004 10:07:58 AM]
Seems to me like you''re answering the question yourself. If you want the flexibility of assigning the same event handler to objects regardless of where their place is in the inheritance tree, then you should use function pointers that can be reassigned.
Virtual functions model a stricter set of relationships that cannot change.
So, how you model your object relationships will determine whether to use virtual functions or "event callbacks."
Virtual functions model a stricter set of relationships that cannot change.
So, how you model your object relationships will determine whether to use virtual functions or "event callbacks."
Author
Well, it occurred to me that the asp.net framework uses virtual functions to implement a special event.
You can handle a ''bubble event'' by overriding ''OnBubbleEvent'' in a web control.
The overriden method even has source and args parameters.
You can handle a ''bubble event'' by overriding ''OnBubbleEvent'' in a web control.
The overriden method even has source and args parameters.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
