Classes - Revision history

Ktrueman: added caveats

2009-07-06T18:26:18Z

added caveats

Ktrueman at 20:59, 7 May 2009

2009-05-07T20:59:34Z

Ktrueman at 20:16, 7 May 2009

2009-05-07T20:16:46Z

Ktrueman at 20:16, 7 May 2009

2009-05-07T20:16:33Z

Ktrueman at 19:30, 7 May 2009

2009-05-07T19:30:19Z

Ktrueman at 19:23, 7 May 2009

2009-05-07T19:23:06Z

Ktrueman at 19:01, 7 May 2009

2009-05-07T19:01:00Z

Ktrueman at 19:00, 7 May 2009

2009-05-07T19:00:30Z

Ktrueman at 18:59, 7 May 2009

2009-05-07T18:59:59Z

Ktrueman at 18:58, 7 May 2009

2009-05-07T18:58:23Z

@@ Line 15: / Line 15: @@
 *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’).
 ----
 Return to the Toolpack [[User Guide]]

@@ Line 11: / Line 11: @@
 *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 Behaviors section.
+*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’).

@@ 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).
-*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 Behaviors section.

@@ Line 6: / Line 6: @@
 Each of these methods has its pros and cons. Therefore, the application designer should carefully select which method applies best to each coding situation:
-<LI>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
+*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).
 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.
-<LI>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 Behaviors section.
+*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 Behaviors section.
-<LI>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’).
-</UL>

← Older revision		Revision as of 19:30, 7 May 2009
Line 16:		Line 16:
	<LI>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’).		<LI>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’).
	</UL>		</UL>
		+
		+
		+	----
		+
		+	Return to the Toolpack [[User Guide]]

@@ 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.
-'''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:

@@ Line 3: / Line 3: @@
 '''Usage'''
-Each of these methods have their pros and cons. Therefore, the designer should select carefully 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:
 <UL>
 <LI>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).

← Older revision		Revision as of 18:58, 7 May 2009
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 ~~instanciated~~ 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.	+	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'''		'''Usage'''