Many of you may have heard that Bedrock is going to use a subset of the Booch Components and are wondering what the Booch Components have to offer. This article gives an overview of what the Booch Components are, compares them to other frameworks and discusses some of the issues associated with integrating and using them with existing frameworks.
The Booch Components are a robust and complete structures and tools class library that provide fundamental data structures and algorithms used in large scale application development. The Booch Components represent a specialized framework in terms of functionality, but at the same time they are a very generalized and flexible framework. The developer can override any of the components and use the mixin inheritance design aspects of the library to build completely new components with new functionality that are tuned for any particular requirement. The Booch Components package consists of 300 files with almost 300 template based classes and some 3000 methods.
The Booch Components take up where MacApp left off. They are a platform independent reusable collection of C++ classes published by Rational and have been designed from the start with performance in mind. They are a second generation class library that take advantage of many of the new C++ features that are now becoming available in C++ compilers like templates and exception handling. The Booch Components structures included in the class library are as follows: Bags, Deques, Graphs, Lists, Maps, Queues, Rings, Sets, Stacks, Trees and Strings. The tools included are Filters, Pattern Matching, Searching, Sorting and Utilities. The Booch Components offer many more types of structures and tools than frameworks like MacApp or TCL and the they are much more flexible in terms of runtime performance and memory utilization.
A brief description of these structures and tools will be given later. It is obvious from the assortment of components available that an application developer can easily find a suitable structure for a given job. The Booch Components are based heavily on templates which allow a structure to provide type safety for the items contained in the structure. The Booch Components also allow the application programmer to choose different forms of each structure or tool based on the requirements of its use. Not only does the developer have a wide selection of components to choose from, but he or she also has a selection of different forms of the component that provide different time/space tradeoffs. The Booch Components are very customizable and use multiple inheritance to derive structures that have a common public interface but completely different implementations. This concept is used to provide different memory management schemes and different methods of process synchronization for each structure.
Anyone who is familiar with an application framework, like MacApp, has come to know and love the power and flexibility of classes derived from TDynamicArray like TList, and TSortedList. And anyone that has written a substantial application in MacApp has also soon realized that these structure classes are not the end all and be all.
After spending a little time with the Booch Components you will come to appreciate the power of the components and at the same time the expressive power of the C++ language.
Each structure has two representations that provide bounded and unbounded forms for each structure. The components use multiple inheritance to provide the common public interface for each structure and the private implementation for each form. Thus the developer can easily choose the form of the structure that is needed for the task at hand. Bounded forms of structures are stack based and unbounded forms are heap based. Each form inherits and uses a different memory management scheme and allows the application to be tuned for performance or memory utilization. Figure 1 illustrates the class hierarchy for the Set Booch Component. This diagram was made using Object Master 2.0 from ACI US which is an excellent tool to use when working with the Booch Components. It allows graphical browsing of template based C++ code. Notice that the two concrete classes Unbounded_Set and Bounded_Set inherit from the abstract class Set and also inherit different memory managers, Simple_List and Simple_Vector respectively. All of the structure components are designed in this way. The bounded and unbounded forms of each structure are concrete and can be instantiated.
The use of mixin inheritance is a powerful feature of the Booch Components and illustrates a very powerful design concept in object oriented programming. The ability to provide an identical public interface while providing totally different implementations allows different forms of the component that have different time and space semantics to be substituted without side effects, other than the recompilation time required for that component. This is an important feature of the Booch Components which is clearly superior to MacApp and TCL. MacApp and TCL structures are all based on TDynamicArray or CArray respectively and have only one form of representation for time and space tradeoff. Even though the MacApp class TList is called a list it is still based on a dynamic array structure. Operations like inserting and deleting are slow since the underlying structure is an array. Insertions and deletions translate into block memory moves which can be very expensive when using large arrays. When using the Booch Components you have a choice for every structure in the library as to which form you wish to use. Using the unbounded form gives you a list based structure where insertions and deletions are optimized, while using the bounded form gives you an array that is more space efficient and is optimized for finding elements. A problem with the bounded forms is that their size must be declared when the template is instantiated: thus array structures in the Booch Components are not dynamic and cannot be resized at runtime. If a dynamic array type of structure is required, it would be quite easy to write a new memory manager based on a dynamic array and substitute this in when creating a new structure. The multiple inheritance design of the components makes this easy to do while still providing the same interface as the other forms.
Figure 2 is a summary of the various components available in the Booch Components class library package. It is not within the scope of this article to explain the functionality of each structure in great detail. There are many good books on data structures that can provide this information.
Figure 3 gives a brief description of the various tools available in the Booch Components class library package.
I am currently looking at a way to integrate the Booch Components with MacApp and am also very interested in using the Symantec tools to compile the Components as well. I will forward any news or progress through MADA and FrameWorks.
Bounded_Set<CStr255, 100>
Templates pose some serious obstacles for the Macintosh developer. MPW CFront is based on v2.0 and will not process templates. Fortunately Rational provides an MPW tool that will preprocess template based C++ code into C++ code that MPW CFront can compile. This tool is called TPL and is invoked prior to the CFront tool in the build sequence. Unfortunately, getting TPL to work with the MABuild script in MacApp is very difficult and is something I am currently working on.
The components come with a complete set of example programs that test each component in the library and each example program comes with the MPW build scripts to compile it. These test programs are very useful when learning the Booch Components as they exercise, from what I could tell, every method of every component in the library. Looking at the build scripts one may soon wonder which is more difficult, writing the actual C++ code or writing the Make files. I am currently looking for ways to simplify this process as well.
// Instantiate the set container class
typedef Node<char> Character_Node;
// Instantiate the unbounded set class
typedef Unbounded_Set<char, Character_Node> Character_Set;
// Instantiate the set iterator class
typedef Set_Active_Iterator<char> Set_Iterator;
void SimpleSetExample( void )
{
Character_Set s1, s2, s3;
// build set of vowels
s1.add('a').add('e').add('i').add('o').add('u');
// build frameworks set
s2.add('f').add('r').add('a').add('m').add('e').add('w').add('o');
// Adding another 'r' here would cause an exception to be thrown,
// Set's don't allow duplicates
// s2.add('r');
s2.add('k').add('s');
s3 = s1; // save set in temporary
s1.intersection(s2); // perform intersection of set s1 and set s2
// Print set s1 which contains intersection of s1 and s2
PrintSet( s1 );
s1 = s3; // restore original s1
s1.set_union(s2); // perform union of set s1 and set s2
// Print set s1 which contains union of s1 and s2
PrintSet( s1 );
}
void PrintSet( Character_Set set )
{
Set_Iterator iter(set);
while (!iter.is_done())
{
fprintf(stdout, "%c", iter.item());
iter.next();
}
}
The example is simple but illustrates several key aspects of the Booch Component Structures. Template instantiation is accomplished via the typedefs and actually creates the classes needed in the code. Iterators are defined and used to traverse the sets and access items in them. The example code illustrates the use of Booch Component iterators in the function PrintSet() and is used to print each character in the set. This example illustrates the power of the Set Booch Component by using some of the classes built in set theory operations. Note that in this example we use the set_union() and intersection() methods to compute the union and intersection respectively of two sets. These methods will work equally well on user defined objects because the user must supply an overloaded equality operator for the item class that will be stored in the set. This allows the set class to compare items in the set and perform the higher level set theory operations. This brings up an important integration issue facing PascalObject derived frameworks and classes.
Using the Booch Components with PascalObject derived frameworks like MacApp and TCL presents a problem due to incompatibilities in C++ objects and PascalObject objects. Most of the Booch Component structures expect that the items or objects that are going to be contained in the structure provide methods that the structure can use. Most structures expect items to provide a default constructor, a copy constructor, assignment operator, and an equality operator. These methods are used internally and called by the structures and must be present for the structure to work properly. This "connection" into the objects contained within the structure allow searching, sorting, insertions and retrievals to operate seamlessly and correctly for any object. The problem with this from a PascalObject point of view is that Pascal Objects do not have and cannot use overloaded operators. This means that PascalObject objects cannot be stored directly in a Booch Component Structure. All objects that are to be stored in a Booch Component structure must be C++ derived. MacApp and TCL programmers can get around this by providing C++ wrapper classes for objects they wish to store in a Booch Structure, but this adds additional complexity and overhead to an application. The Booch Components must be used with true C++ derived objects. Of course this limitation will not be a problem in MacApp 3.1 where all objects are true C++ and the PascalObject dependency has been eliminated.
