Interfaces - Revision history

Ktrueman: /* Usage */ added image of CMC interfaces

2009-07-06T18:36:25Z

Usage: added image of CMC interfaces

Ktrueman: /* Usage */

2009-05-08T13:43:13Z

Usage

Ktrueman at 20:57, 7 May 2009

2009-05-07T20:57:37Z

Ktrueman: /* Usage */

2009-05-07T20:56:34Z

Usage

Ktrueman at 19:30, 7 May 2009

2009-05-07T19:30:05Z

Ktrueman at 18:54, 7 May 2009

2009-05-07T18:54:38Z

Ktrueman at 18:52, 7 May 2009

2009-05-07T18:52:34Z

Ktrueman: New page: Interfaces are basically a set of member functions that act as an API to an object. Implemented as pure-virtual base classes (i.e. can only be used through inheritance), these APIs are use...

2009-05-07T18:49:36Z

New page: Interfaces are basically a set of member functions that act as an API to an object. Implemented as pure-virtual base classes (i.e. can only be used through inheritance), these APIs are use...

New page

Interfaces are basically a set of member functions that act as an API to an object. Implemented as pure-virtual base
classes (i.e. can only be used through inheritance), these APIs are used by other modules of the system to interact with
all types of objects without knowing their specific definitions (i.e. having to include an header file with the description
of the class). One can see these interfaces as a set of functions that everybody knows how to call. As long as a class
inherits from an interface, any object that knows this interface can use the class. This design approach is commonly
use to create systems where the implementation of a specific functionality is irrelevant or need to be replaceable. For
example, a database interface would define member functions to read and write records from a database. Multiple
classes deriving from that interface could implement it differently such as using an XML file instead of a real database
or storing the information into RAM. The benefit from this is that any other piece of code in the system only need to
be passed a pointer to the interface regardless of the type of the class implementing it. Thus, there is no knowledge of
the actual class implementing the interface.

@@ Line 10: / Line 10: @@
 A practical example is the implementation of the the ToolPack wrapper classes on top of the CMC API:
-'''IMAGE MISSING'''
+[[Image:CMC interfaces.jpg ]]
-As shown in the above figure, the CMC library does not actually knows which classes implements the different functional APIs. It only knows of the pointers to the interfaces to each different service. Whether or not these interfaces are implemented into a single object or multiple objects is irrelevant to the CMC library.
+As shown in the figure above, the CMC library does not actually knows which classes implements the different functional APIs. It only knows of the pointers to the interfaces to each different service. Whether or not these interfaces are implemented into a single object or multiple objects is irrelevant to the CMC library.
 == Caveats ==

@@ Line 10: / Line 10: @@
 A practical example is the implementation of the the ToolPack wrapper classes on top of the CMC API:
-IMAGE MISSING
+'''IMAGE MISSING'''
 As shown in the above figure, the CMC library does not actually knows which classes implements the different functional APIs. It only knows of the pointers to the interfaces to each different service. Whether or not these interfaces are implemented into a single object or multiple objects is irrelevant to the CMC library.
 == Caveats ==

← Older revision		Revision as of 20:57, 7 May 2009
Line 13:		Line 13:

	As shown in the above figure, the CMC library does not actually knows which classes implements the different functional APIs. It only knows of the pointers to the interfaces to each different service. Whether or not these interfaces are implemented into a single object or multiple objects is irrelevant to the CMC library.		As shown in the above figure, the CMC library does not actually knows which classes implements the different functional APIs. It only knows of the pointers to the interfaces to each different service. Whether or not these interfaces are implemented into a single object or multiple objects is irrelevant to the CMC library.
		+
		+
		+	== Caveats ==
		+	Be aware that some interface member functions may have default implementation while some other absolutely need '''SENTENCE IS INCOMPLETE'''

← Older revision		Revision as of 20:56, 7 May 2009
Line 8:		Line 8:
	== Usage ==		== Usage ==

−	~~ THIS PAGE IS MISSING THE SECTION ON USAGE ~~	+	A practical example is the implementation of the the ToolPack wrapper classes on top of the CMC API:

		+	IMAGE MISSING

		+	As shown in the above figure, the CMC library does not actually knows which classes implements the different functional APIs. It only knows of the pointers to the interfaces to each different service. Whether or not these interfaces are implemented into a single object or multiple objects is irrelevant to the CMC library.

← Older revision		Revision as of 19:30, 7 May 2009
Line 5:		Line 5:
	For example, a database interface would define member functions to read and write records from a database. Multiple classes deriving from that interface could implement it differently such as using an XML file instead of a real database or storing the information into random access memory (RAM). The benefit from this approach is that any other piece of code in the system only needs to be passed a pointer to the interface regardless of the type of the class implementing it. Thus, there is no knowledge of the actual class implementing the interface.		For example, a database interface would define member functions to read and write records from a database. Multiple classes deriving from that interface could implement it differently such as using an XML file instead of a real database or storing the information into random access memory (RAM). The benefit from this approach is that any other piece of code in the system only needs to be passed a pointer to the interface regardless of the type of the class implementing it. Thus, there is no knowledge of the actual class implementing the interface.

		+
		+	== Usage ==

	THIS PAGE IS MISSING THE SECTION ON USAGE		THIS PAGE IS MISSING THE SECTION ON USAGE
		+
		+
		+
		+
		+	----
		+
		+	Return to the Toolpack [[User Guide]]

← Older revision		Revision as of 18:54, 7 May 2009
Line 4:		Line 4:

	For example, a database interface would define member functions to read and write records from a database. Multiple classes deriving from that interface could implement it differently such as using an XML file instead of a real database or storing the information into random access memory (RAM). The benefit from this approach is that any other piece of code in the system only needs to be passed a pointer to the interface regardless of the type of the class implementing it. Thus, there is no knowledge of the actual class implementing the interface.		For example, a database interface would define member functions to read and write records from a database. Multiple classes deriving from that interface could implement it differently such as using an XML file instead of a real database or storing the information into random access memory (RAM). The benefit from this approach is that any other piece of code in the system only needs to be passed a pointer to the interface regardless of the type of the class implementing it. Thus, there is no knowledge of the actual class implementing the interface.
		+
		+
		+	THIS PAGE IS MISSING THE SECTION ON USAGE

@@ Line 1: / Line 1: @@
-Interfaces are basically a set of member functions that act as an API to an object. Implemented as pure-virtual base
+Interfaces are basically a set of member functions that act as an application programming interface (API) to an object. Implemented as pure-virtual base classes (i.e., they can only be used through inheritance), these APIs are used by other modules of the system to interact with all types of objects without knowing their specific definitions (i.e., having to include an header file with the description of the class).
 classes (i.e. can only be used through inheritance), these APIs are used by other modules of the system to interact with
-all types of objects without knowing their specific definitions (i.e. having to include an header file with the description
+One can see these interfaces as a set of functions that everyone knows how to call. As long as a class inherits from an interface, any object that knows of this interface can use the class. This design approach is commonly used to create systems where the implementation of a given functionality is irrelevant or needs to be replaceable.
-of the class). One can see these interfaces as a set of functions that everybody knows how to call. As long as a class
-inherits from an interface, any object that knows this interface can use the class. This design approach is commonly
+For example, a database interface would define member functions to read and write records from a database. Multiple classes deriving from that interface could implement it differently such as using an XML file instead of a real database or storing the information into random access memory (RAM). The benefit from this approach is that any other piece of code in the system only needs to be passed a pointer to the interface regardless of the type of the class implementing it. Thus, there is no knowledge of the actual class implementing the interface.
-use to create systems where the implementation of a specific functionality is irrelevant or need to be replaceable. For
 example, a database interface would define member functions to read and write records from a database. Multiple
 classes deriving from that interface could implement it differently such as using an XML file instead of a real database
-or storing the information into RAM. The benefit from this is that any other piece of code in the system only need to
 be passed a pointer to the interface regardless of the type of the class implementing it. Thus, there is no knowledge of
 the actual class implementing the interface.