Behaviors

From TBwiki
(Difference between revisions)
Jump to: navigation, search
Line 9: Line 9:
 
*Your bright ideas...
 
*Your bright ideas...
  
The decorator pattern is used by behaviors to provide this level of flexibility; behaviors decorate the default ITBCAFCall subclasses doings. A specific behavior can be used on any ITBCAFCall subclasses, as long as they are compatible in their doings e.g. Using a generic "Follow Me" behavior might not work as intended on a prepaid call).
+
The decorator pattern is used by behaviors to provide this level of flexibility; behaviors decorate the default [[TBCAF::ITBCAFCallClassReference|ITBCAFCall]] subclasses doings. A specific behavior can be used on any ITBCAFCall subclasses, as long as they are compatible in their doings e.g. Using a generic "Follow Me" behavior might not work as intended on a prepaid call).
  
 
Additionally, protocol specific behaviors can be created to remove any protocol aware code in the base classes. These behaviors can then be dynamically added to the calls depending on their protocol.
 
Additionally, protocol specific behaviors can be created to remove any protocol aware code in the base classes. These behaviors can then be dynamically added to the calls depending on their protocol.

Revision as of 08:45, 8 May 2009

Services must usually contain a variable number of features. Coding all these features in the ITBCAFCall subclasses might become hard to maintain has the number of features increase. Behaviors provide a way to implement these features in separate classes which are attached to a call at runtime. Basically a behavior traps all events for a call’s legs so it can act on the events and optionally forward them to the rest of the behavior chain. This chain is constructed at the initialization of the call as seen in the next section so that every call can have a different chain (therefore different features).

Here are examples of features that make good behaviors:

  • Ringback tones
  • Voicemail fallback
  • Follow me
  • Call detail record
  • Fax relay (over VOIP)
  • Your bright ideas...

The decorator pattern is used by behaviors to provide this level of flexibility; behaviors decorate the default ITBCAFCall subclasses doings. A specific behavior can be used on any ITBCAFCall subclasses, as long as they are compatible in their doings e.g. Using a generic "Follow Me" behavior might not work as intended on a prepaid call).

Additionally, protocol specific behaviors can be created to remove any protocol aware code in the base classes. These behaviors can then be dynamically added to the calls depending on their protocol.

Behaviors could be implemented through simple inheritance but it is less flexible. Indeed, a class for each combination of features would be required; so the classes needed for the example below would be:

  • CMyCall
  • CMyCallRingbackTone
  • CMyVoiceMailFallback
  • CMyCallRingbackToneVoiceMailFallback
  • CMyVoiceMailFallbackCallRingbackTone (makes no sense in this case but it could make sense for some behaviors) Since the number of classes would be an exponetial of the number of features, we deemed this not acceptable and used decoration instead.


Usage

Behaviors must be subclasses of CTBCAFCallBehavior which delegates all events to it’s parent by default. The new behavior must implement the event handlers only for the events it needs and must decide whether or not to delegate the event (capturing the event or letting others use it). The CTBCAFCallBehaviorRbt, CTBCAFCallBehaviorVoiceMail, CTBCAFCallBehaviorFollowMe, CTBCAFCallBehaviorFaxRelay classes are good examples of all kinds of simple behaviors.

The following code demonstrates how to decorate a call with ringback tone and voicemail fallback behaviors:

 {
   pCall = tbnew CMyCall(...);
   pRbtCall = tbnew CMyCallBehaviorRbt( pCall );
   pVoiceMailRbtCall = tbnew CMyCallBehaviorVoiceMailFallback( pRbtCall );
 }


Caveats

Behaviors should be careful with the state of the call since the may be used on any type of call. For example a check should be made to be shure a leg exists before using it. This should prevent crashes in case of invalid usage of the behavior.




Return to the Toolpack User Guide

Personal tools