What are some examples of using the CALLBACK pattern / idiom?
I use callbacks almost every day in the following scenarios:
-
Events. When the user clicks on a control, presses a key, or otherwise interacts with the user interface in a way that I need to handle, I subscribe to the delegate that the control publishes for the event. Then I can handle it by updating the UI, canceling the event in certain circumstances, or otherwise doing some special action.
-
Multi-threaded programming: When programming the GUI, it is important to keep the UI responsive and indicate the progress of a long-term background event for the user. To do this, I run the task on a separate thread and then post delegates (events in the .NET world) that provide my UI with the ability to inform the user of the progress made.
-
Lambda Functions: In .NET, lambda functions are a form of delegate that allows me to interact with another part of an operation with code at a later point in time. LINQ is a great example of this. I can create a small match function and then pass it to a LINQ query. Later, when I execute my query against the collection, the match function is called to determine if there is a match for the query. This keeps me from creating or worrying about the request mechanism. I just have to tell the query engine where to go to figure out if the comparison is a match or not.
These examples will just scratch the surface, I'm sure. But they are useful examples of how I use callbacks every day.
source to share
Callbacks are not really "templates" - more like a building block. A number of group of four design patterns use virtual methods in the callback. Justin Nissner has already mentioned the Observer .
Callbacks are much older than OOP (and probably older than 3GL and even assembler). Another old idea is a parameter block - the C interpretation is a structure full of related members that must be passed to a function, so the function doesn't need a huge parameter list.
OOP classes are based on the parameter block (and add philosophy to it). The class instance itself is a block of parameters passed by reference to its methods. The virtual table is a block of send processing parameters. Each virtual method has a callback pointer in the dispatch processing parameter block. A pure virtual method reserves space for the callback pointer in the parameter block and promises to provide the actual pointer later.
Since a class is the building block for OOP design patterns, and block blocks and callbacks are the building blocks of classes - well, you can argue that all OOP design patterns are built from these ideas.
I'd like to say "parameter blocks and callbacks, and style rules guiding their use, inspired object orientation", but as attractive as it sounds, I don't know if that's true.
source to share
The C object and Cocoa structure are very useful. An example might be NSURLConnection
, which will inform an object (called a delegate ) of this when something happens in the connection:
NSURLConnection *foo = [[NSURLConnection alloc] initWithRequest:request delegate:self];
Pay attention to the passage delegate
. The request is executed in the background and the instance then sends messages to the delegate (in this case self
), for example:
connectionDidFinishLoading:
connection:didFailWithError:
You get the idea. I believe this is called the "observer pattern". This is all related to the Cocoa event loop (as far as I know, I'm still involved) and is cheap asynchronous programming. This approach suits many structures in different languages.
.NET also has delegates similar to. Think about events.
source to share