| Overview | Package | Class | Tree | Index | Help |
|
|||||||||
| PREV NEXT | FRAMES NO FRAMES All Classes | ||||||||
Every effort is taken to ensure that the Java and C++ versions of the Veterinary HL7 Library are consistent with each other at all levels of abstraction. In some cases this leads to C++ that uses techniques more familiar to Java programmers. In a few others it leads to C++-like Java. In a few cases the underlying language or library differences force differences in the implementation details between the two libraries. These differences are outlined in this document.
Java provides an extensive run-time typing system that is not completely replicated by C++'s relatively new run-time type information system. Most significantly, C++ provides no equivalent of the Java Class.forName( String ) method. We replace this functionality by using each of the generic base classes as factories to create one of their derived classes based on a string class name. The key interface method is makeXXX( String ).
The current factory implementation uses a collection of objects of each type in a static hashtable keyed on the class name. When new instances are needed, the template object is accessed via the class name key and its newInstance() method is used to create the new object. This requires populating all known classes in the hashtable. An addXXXType() method for each factory type allows types added by library users to be properly instantiated by name. This is clunky but works for now.
TODO: Add detailed discussion of this mechanism and all methods related to it.
The Java version of the library makes extensive use of Java's automatic garbage collection feature. Of course, this does not exist in C++. In its place, we use each container's destructor to delete not only that object's members, but each of the objects held in its container. This works well, but prevents us from storing references to the same object in more than one container. This becomes an issue when we use constant objects for such things as coded entries from LOINC or SNOMED codes. The current solution is to clone these objects and put a distinct instance in each collection. It would be more efficient to track instances using a mechanism such as smart pointers. ANY C++ GURUS WANT TO TAKE THIS ON?
TODO: Add detailed discussion of this mechanism and all methods related to it.
C++ provides for more strict constant object and method enforcement. We have attempted to use const enforcement effectively. The Java version uses the same " get()" methods to get an existing object to read and to get or create an object in context to write. This tends to breakdown the C++ const correctness. Thus, each get method that returns a container object in the C++ version has two versions; the normal "get()" method that is declaired const and returns a const object, and a "getXXXToWrite()" that is not const and returns a modifiable container.
TODO: Add detailed discussion of this mechanism and all methods related to it.
Within the implementation details, there are a number of interactions via methods that are not intended for "public" consumption. These have package scope in the java implementation. They could properly use "friend class" declarations in C++ but for now use a number of public methods that should really be private or protected with friend access for other implementation classes
TODO: Implement correct scoping.
|
|
||||||||
| PREV NEXT | FRAMES NO FRAMES All Classes | ||||||||