Callback function as a parameter

[umlinfo]

Hi,
  I have a problem in representing a callback function as one of the parameters to another function.
Right now, I am just using a void pointer.

Alternately,
I would define
  typedef void (*pCallback)(unsigned long events);
How do I represent this typedef using EA, so that I get pCallback in the "Type" listing.

Thanks.

[«Midnight»]

Try reverse engineering one into EA. Then examine the resulting elements to see if there is a stereotype or tagged value that indicates this is a callback.

[umlinfo]

Hi, good idea about revese engg. Assuming I will implement a typedef in the code, I can specify the Type of the parameter as a function pointer pCallback*, which solve my problem.
Thanks.

[«Midnight»]

Don't know for sure, and typedefs have to be handled 'just so' in EA.

Do a thorough search of this forum for more information. Pay attention to those threads where Sparx personnel have participated.

[sl@sh]

As another thought: in a recent project we were using callback mechanisms extensively. We modelled this as a call providing a callback object as a parameter. This object was of type class, or more precisely an abstract class (an interface). This class provided a pure virtual function which the called object then could use to notify the caller once it was done, and to pass any resulting values of the operation.

There were basically two approaches to pass such a callback object: either there was a seperate class, implementing the interface class, which was instantiated by the caller and passed to the called object, or the caller was derived from the interface class itself, so it could pass itself as the callback object. The latter apparently is the easier approach, but in some cases, when certain classes would call a lot of others using the callback mechanism, using seperate callback class implementations proved to provide a much cleaner and easier to maintain code. Also in some cases it turned out we could use one callback implementation class for several different classes, avoiding redundancy.

There are multiple advantages to this approach:

• You don't need potentially unsafe type casts
  
• You can visualize your callback dependencies in your class diagrams
  
• You can freely pass an arbitrary number of values or objects back to the caller
  
• The called object doesn't need to know the caller, just the callback interface class
  
• You can easily model callbacks to a family of class objects by implementing just one callback interface and sharing this for each of your family's classes
  

HTH,
Stefan