Classes
From TBwiki
(Difference between revisions)
(added caveats) |
|||
| (2 intermediate revisions by one user not shown) | |||
| Line 9: | Line 9: | ||
*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 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). | ||
| − | *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 | + | *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. |
| − | 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. | + | |
| − | *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 | + | *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]]. |
*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. 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’). | ||
| + | |||
| + | == Caveats == | ||
| + | |||
| + | None at this time. | ||
---- | ---- | ||
Return to the Toolpack [[User Guide]] | Return to the Toolpack [[User Guide]] | ||
Latest revision as of 13:26, 6 July 2009
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.
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 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).
- 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.
- 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.
- 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’).
Caveats
None at this time.
Return to the Toolpack User Guide
