Actions

Classes: Difference between revisions

(added caveats)
mNo edit summary
 
Line 1: Line 1:
In this documentation, a system programmer will see that multiple classes exists that implements one or many interfaces. A few number of these classes are designed to be base classes (i.e. cannot be instantiated and need to be inherited) while the vast majority are available to use directly into the application code. The Toolpack architecture allows a developer to use these classes and to modify their behavior in various ways.
{{DISPLAYTITLE:Classes}}
In this article, a system programmer will see that multiple classes exist that implement one or many interfaces. A few of these classes are designed to be base classes (i.e. cannot be instantiated and need to be inherited), while the vast majority are available to use directly in the application code. The Toolpack architecture allows a developer to use these classes and to modify their behavior in various ways.




Line 7: Line 8:
Each of these methods has its pros and cons. Therefore, the application designer should carefully select which method applies best to each coding situation:
Each of these methods has its pros and cons. Therefore, the application designer should carefully select which method applies best to each coding situation:


*Use the classes 'as-is' by instantiating them in the code (using ’new’) This method should be used if the class meet 100% of the requirements in terms of interface (APIs to other component of the system) and behavior in the implementation. If those conditions are met, this is definitely the simplest way of coding fast and robust applications (i.e. code re-use).
*Use the classes 'as-is' by instantiating them in the code (using ’new’) This method should be used if the class meets 100% of the requirements in terms of interface (APIs to other component of the system) and behavior in the implementation. If these conditions are met, this is definitely the simplest way of coding fast and robust applications (i.e. code re-use).


*Derive from the classes to modify the implementation but still benefit from the class’ default implementation. This method should be used if the class interfaces meet the requirements and only a small set of behavior needs to be adjusted. To do so, the developer must be aware of the behavior of the underlying class to avoid usual coding problems (e.g. double free of some structures, etc). This method is typically fast to implement but can create many different classes if multiple inheritance is required. For example, ring-back-tone, follow-me and voicemail-fallback can be designed as derived class. However, if a system needs to handle cases where combinations of those service are to be used, this would lead to having a class for every combination.
*Derive from the classes to modify the implementation but still benefit from the class’ default implementation. This method should be used if the class interfaces meet the requirements and only a small set of behavior needs to be adjusted. To do so, the developer must be aware of the behavior of the underlying class to avoid the usual coding problems (e.g. double free of some structures, etc). This method is typically fast to implement but can create many different classes if multiple inheritance is required. For example, ring-back-tone, follow-me and voicemail-fallback can be designed as derived classes. However, if a system needs to handle cases where combinations of those services are to be used, this would lead to having a class for every combination.


*Use the ’behavior’ concepts to modify the flow of the class by using it rather than inheriting from it (this only applies to some CAF classes). This method has the advantage of being easily cascadeable as long as the different behavior are not conflicting with each other. This is covered in more details in the section on [[Behaviors]].
*Use the ’behavior’ concepts to modify the flow of the class by using it rather than inheriting from it (this only applies to some CAF classes). This method has the advantage of being easily to cascade as long as the different behavior are not conflicting with each other. This is covered in more detail in the section on [[Behaviors]].


*Recreate a new class from the start by inheriting from the same interfaces as the original class. Sometime, the default implementation of a class is too far away from what the system designer wants to achieve. In these situation, it is better to start a new class inheriting from the same interfaces as the studied class. Anyhow, as described in the previous section, as long as it derives from the proper interfaces, only minimal code change will be required in the system to use this new proprietary class (usually change the code line that does the ’new’).
*Recreate a new class from the start by inheriting from the same interfaces as the original class. Sometimes, the default implementation of a class is too far away from what the system designer wants to achieve. In this situation, it is better to start a new class, inheriting from the same interfaces as the studied class. As described in the previous section, as long as it derives from the proper interfaces, only minimal code change will be required in the system to use this new proprietary class (usually change the code line that does the ’new’).





Latest revision as of 10:33, 9 September 2022

In this article, a system programmer will see that multiple classes exist that implement one or many interfaces. A few of these classes are designed to be base classes (i.e. cannot be instantiated and need to be inherited), while the vast majority are available to use directly in the application code. The Toolpack architecture allows a developer to use these classes and to modify their behavior in various ways.


Usage

Each of these methods has its pros and cons. Therefore, the application designer should carefully select which method applies best to each coding situation:

  • Use the classes 'as-is' by instantiating them in the code (using ’new’) This method should be used if the class meets 100% of the requirements in terms of interface (APIs to other component of the system) and behavior in the implementation. If these conditions are met, this is definitely the simplest way of coding fast and robust applications (i.e. code re-use).
  • Derive from the classes to modify the implementation but still benefit from the class’ default implementation. This method should be used if the class interfaces meet the requirements and only a small set of behavior needs to be adjusted. To do so, the developer must be aware of the behavior of the underlying class to avoid the usual coding problems (e.g. double free of some structures, etc). This method is typically fast to implement but can create many different classes if multiple inheritance is required. For example, ring-back-tone, follow-me and voicemail-fallback can be designed as derived classes. However, if a system needs to handle cases where combinations of those services are to be used, this would lead to having a class for every combination.
  • Use the ’behavior’ concepts to modify the flow of the class by using it rather than inheriting from it (this only applies to some CAF classes). This method has the advantage of being easily to cascade as long as the different behavior are not conflicting with each other. This is covered in more detail in the section on Behaviors.
  • Recreate a new class from the start by inheriting from the same interfaces as the original class. Sometimes, the default implementation of a class is too far away from what the system designer wants to achieve. In this situation, it is better to start a new class, inheriting from the same interfaces as the studied class. As described in the previous section, as long as it derives from the proper interfaces, only minimal code change will be required in the system to use this new proprietary class (usually change the code line that does the ’new’).


Caveats

None at this time.


Return to the Toolpack User Guide