Enhancing the Manager Class 167
// Generate a report to see what is in use.
f.Report();
}
3. Save the file and close the code editor.
4. Compile the entire program and run it in the operating system of your choice.
You should see the following output if you have done everything right. Note that depending on your operating system and hardware, the actual numbers shown for addresses will vary.
$ ./a.exe Found one
I got back a MyObject1 object Object at a050230 in use
I am a MyObject1 Object Object at a050008 in use I am a MyObject2 Object Object at a050638 in use I am a MyObject3 Object
This output shows us that the manager is keeping track of our various base Object-derived classes and creating them only when necessary. As you can see, the virtual methods permit us to create the proper type for this particular derived class and to create them as needed.
As you can see, the factory manager can handle all sorts of different kinds of objects — as long as they are derived from a common base class. In addition, our virtual methods can be used to differentiate the objects to let other programmers know what we can do.
Enhancing the Manager Class
One way you might consider enhancing the manager class is to extend it by letting it allocate its own objects. As the code stands, the manager manages only the objects that are added to its list. It cannot create new ones as they are needed. If all of the allocations were done in one place, tracking down problems with memory leaks, allocation errors, and usage patterns would be vastly simpler. This could be done in a variety of ways, from registering a “constructor” function that would be passed to the manager, to adding code to create specific forms of the objects. The latter case is easier, the former case more extensible and flexible.
If you want another bit of programming fun, you can add another good feature to add to the manager: Implement a method that would delete all objects in the class, notifying the objects if necessary. This “clean” method could be called at program shutdown, in order to guarantee that there are no memory leaks in the application. In addition, you could use the Report method (shown in Listing 28-1 at 1) at various times in your application to ensure that you are not leaving orphan objects in the system that are not eventually de-allocated.
There is one other way to implement a manager, which is worth a mention. You can create a manager that is a friend class to all of the classes it needs to manage. If you use this technique, you should create a method within the managed class that knows how to “clone” itself. This would essentially be a method that allocated a new object, called its copy constructor with itself as an argument, and returned the newly created object to the manager. With this technique, the manager doesn’t need to worry about how to create objects; all it has to do is find the ones it manages in its list.
29 Using Mix-In
Classes
Technique
Save Time By
Understanding mix-in classes
Implementing mix-in classes
Testing your code
Inheritance is an extremely powerful technique in C++. The problem with inheritance, however, is that you must either give the end-user access to all public methods of a class — or override them privately to
“hide” them from use by the end-user. C++ takes an all-or-nothing approach to the derivation of classes with inheritance. This approach is hardly an optimal technique, because removing the undesired functionality from a class that contains many methods would require more work than recreating the class from scratch. For example, if you are inheriting from a class that contains a print method, and you do not want that method exposed to the end-user, you must hide the method by creating a new, private version of it. This is not too difficult when there is only one such method, but when there are a dozen of them, it makes more sense to create a new class.
Fortunately, C++ provides an alternative: the mix-in class. Here’s how it works: The easiest way to limit the functionality you provide from a base class is to use that class as a data member of the inherited class — and to give the end-user access only to the methods you want them to use, instead of providing all methods and removing the ones you don’t want used. This approach is particularly useful when you have small classes you want to initialize and restrict (so that only you have access to them), or classes whose overall functionality is more than you feel comfortable providing (or is too complicated for the end-user to deal with). The embedded base class is a mix-in to the inherited class.
Mix-in classes are implemented as data members of the class that provides the overall functionality and are used to extend that functionality. The advantages of the mix-in technique are obvious: It gives the user access to the capabilities you want used, you can restrict what the users have access to, and you can simplify the methods provided by providing your own wrappers with defaults. When your mix-in class is embedded in a class the user may instantiate, you control what methods in the mix-in class are available. To do this, you simply write accessor methods that
Implementing Mix-In Classes 169
allow the end-user access to the methods you want them to be using in the mix-in class. This has several advantages. First, you control what access the user has to functionality. Second, if you change the way in which the embedded mix-in class works, the enduser is not impacted. Finally, you can adapt the functionality of the mix-in class to your specific needs, tailoring its behavior within your wrapper methods. Because you do not have to write the entire functionality provided by the mix-in, you save a lot of time, and the usesr get a fully debugged system, saving them time.
Provide access to selected functionality in a class by using that class as a mix-in. You can easily extend your own classes and move informationspecific data into a class that handles that data only. This is particularly important when working with classes that encapsulate data that would be easily destroyed, corrupted, or overwritten if you provided direct access to the data members.
Implementing Mix-In Classes
Assume you want to add the ability to save data in one of your classes. You could add a base class called Save that permits data to be written to a file. This class would do all the work of managing the output file, writing to it, and closing it. Then you could create a mix-in class to do the save functionality, and then illustrate how that functionality is used in a derived class.
To implement a mix-in class, you simply do the following steps in your own existing class:
1. In the code editor of your choice, create a new file to hold the code for the implementation of the source file.
In this example, the file is named ch29.cpp, although you can use whatever you choose.
2. Type the code from Listing 29-1 into your file.
Better yet, copy the code from the source file on this book’s companion Web site.
LISTING 29-1: THE MIX-IN CLASS
#include <stdio.h> #include <string>
class Save
{
FILE *fp; public:
Save( void )
{
} |
fp |
= |
NULL; |
|
|
|
|
|
|
|
|
Save( const char *strFileName ) |
|
|
|||
{ |
fp = |
fopen( strFileName, “w” ); |
1 |
||
} |
|||||
virtual |
~Save() |
|
|
||
{ |
if ( |
fp ) |
|
|
|
|
2 |
||||
} |
|
fclose(fp); |
|||
void Write( const char *strOut ) |
|
3 |
|||
{ |
|
|
|
|
|
if ( fp )
fprintf(fp, “%s\n”, strOut );
}
void Write( int i )
{
if ( fp )
fprintf(fp, “%d\n”, i );
}
void Write( double d )
{
if ( fp )
fprintf(fp, “%ld\n”, d);
}
FILE *getFilePointer()
{
return fp;
}
};
(continued)
170 Technique 29: Using Mix-In Classes
LISTING 29-1 (continued)
class |
MyClass |
|
{ |
|
|
private: |
|
|
Save s; |
|
|
public: |
|
|
MyClass( void ) |
4 |
|
{ |
: s(“test.txt”) |
|
} |
s.Write(“Start of MyClass”); |
5 |
MyClass( const char *strFileName ) |
|
|
{ |
: s(strFileName) |
|
s.Write(“Start of MyClass”); |
|
|
} |
|
|
|
|
|
virtual ~MyClass() |
|
|
{ |
s.Write(“End of My Class”); |
6 |
} |
||
void Log( const char *strLog )
{
s.Write(strLog);
}
};
int main(int argc, char **argv)
{
MyClass mc;
for ( int i=0; i<argc; ++i ) mc.Log( argv[i] );
return 0;
}
In the above listing, the Save functionality is implemented in a mix-in class, which is used by the MyClass class to give the end-user the ability to save data from the MyClass member variables. Note that the end-user has no access to the Save functionality directly, but instead uses it through the Log method, which utilizes the save functions but does not directly expose them.
3. Save the source file in your code editor and
Compiling and Testing
Your Mix-In Class
Let’s verify that the code works as illustrated and allows you to save data within the MyClass objects. To do this, we will compile and run the program and view the output. The following steps show you how:
1. Compile the source code with the compiler of your choice on the operating system of your choice.
Note that we have implemented all of the file handling functionality — the open (shown at 1), close (shown at 2), and save functions of the file — in the mix-in class Save. This class deals with all the operating-system-specific work of dealing with file pointers. Our main class in the example, MyClass, simply works with the mix-in class and assumes that it knows what to do for various combinations of operating systems and environments.
Always move all operating-system-specific functionality for file systems, memory handling, time functions, and the like, into mix-in classes that you can embed in your code. Doing so ensures that the code is easily portable between different operating systems, compilers, and environments.
2. Run the program in the operating system shell of your choice.
If you have done everything properly, you should get no output from the program itself. Instead, you see a file which we defined in the MyClass class at 4 (called test.txt) generated in the file system, residing in the directory in which you ran the program. This file should contain the output shown in Listing 29-2.
close the code editor.
Compiling and Testing Your Mix-In Class |
171 |
LISTING 29-2: THE TEST.TXT OUTPUT FILE
Start of MyClass |
|
7 |
|
./a |
|
|
|
End |
of My Class |
8 |
|
As you can see from the output, the program logs some data of its own, indicating the beginning and end of the class lifespan. In addition, it allows the user to output the arguments to the program.
Because we did not provide any arguments, it simply outputs the name of the executable file, which is the first argument to all programs.
Notice that our class logs its own actions (see |
5 |
|||
and 6, these are shown in the output file at |
|
7 |
||
and |
8 |
) as well as the actions of the class it |
is |
|
|
|
|
||
called from. This handy characteristic provides you
with an essential debugging log from which you can look at how the program is operating.
Part V
Arrays and Templates
30 Creating a Simple
Template Class
Technique
Save Time By
Making classes reusable by making them generic
Comparing void pointers to template classes
Implementing template classes
Understanding your output
Because our classes can be reused over and over again in C++, we want to create as general a class as we can so it can be used in the broadest possible variety of applications. For example, it doesn’t
make much sense to create a class that can print out copyright information for only a specific company, such as
(c) Copyright 2004 MySoftwareCompany Inc.
It would make a lot more sense to create a class that printed out a copyright symbol, added the company name from an initialization file, and then added the year from passed-in arguments (or from the current year as specified by the computer clock). Allowing data to be inserted from external sources makes the class more generic, which in turn makes it more usable across different applications.
This is the very heart of the C++ construct known as templates. A template is, as its name implies, something that can be customized for specific forms of data. For example, consider a class that handled pointers to given data types. The class would have the data type hard-coded into it, and handle only that particular type of pointer. This class would be useful if it handled a specific data type, such as a class named Foo. However, the class would be even more useful if it handled all the various data types that can be assigned to pointers. In C, we handled heterogeneous arrays of pointers by using void pointers, which were pointers to blocks of memory that did not know what kind of structure, data type, or class the block was meant to be. Unfortunately, with C++, void pointers are ineffective. For example, consider the code in Listing 30-1:
176 Technique 30: Creating a Simple Template Class
LISTING 30-1: WORKING WITH VOID POINTERS
#include <stdio.h> #include <string.h>
void delete_func( void *obj )
{
if ( obj ) delete obj;
} |
|
|
class Foo |
|
|
{ |
|
|
char *s; |
|
|
public: |
|
|
Foo( const char *strTemp ) |
|
|
{ |
|
|
printf(“Constructor for foo\n”); |
|
|
s = new char[strlen(strTemp)+1]; |
|
|
strcpy(s, strTemp); |
|
|
} |
|
|
virtual ~Foo() |
|
|
{ |
|
|
printf(“Destructor for foo\n”); |
|
|
delete s; |
|
|
} |
|
|
}; |
|
|
int main() |
|
|
{ |
|
1 |
Foo *f = new Foo(“This is a test”); |
|
|
func(f); |
|
}
The above listing illustrates how a pointer can be treated as “generic” — that is, having no type. In the main program (shown at 1), we create a new Foo object using the standard constructor for the class. This pointer is then passed to the func function, which deletes the pointer, without knowing what type it is. If the destructor for the class were called, we would see two output lines, one for the construction of the class and one for the destruction.
If you were to compile this program and run it, you would see output that said:
Constructor for foo
with no corresponding destructor call for the object. Why? Because at run-time. the program does not “know” what sort of object obj is in the delete_func function, and therefore cannot call the destructor for the object. In order for the function to “know” what the object it receives is, we must pass it by type. If we are writing a manager of pointers, it would certainly be useful to know what the data types were, so that we could destroy them properly. In order to avoid the problem of void pointers, we could simply derive all objects from a common base type, such as an Object type and then call that destructor for all objects. The problem with this is that it not only introduces overhead in creating the objects, and requires extra space for the base class, it creates problems with multiple inheritance. (For more on multiple inheritance, see Technique 22.) There is really no reason to introduce extra complications when there are simpler approaches possible, and the simpler approach, in this case, is to use C++ t emplates. Templates will save you time and effort
by reducing the amount of code written and generalizing solutions that can be used across multiple projects.
1. In the code editor of your choice, create a new file to hold the code for the implementation of the source file.
In this example, the file is named ch30.cpp, although you can use whatever you choose.
2. Type the code from Listing 30-2 into your file.
Better yet, copy the code from the source file on this book’s companion Web site.
LISTING 30-2: THE TEMPLATE APPROACH
#include <stdio.h> #include <string.h> #include <vector>
template <class A> |
|
5 |
class Manager |
|
{
Technique 30: Creating a Simple Template Class |
177 |
std::vector< A *> _objects; |
|
7 |
public: |
|
Manager()
{
}
~Manager()
{
Clean();
}
void AddInstance( A *pObj )
{
_objects.insert( _objects.end(), pObj
);
}
void Clean()
{
std::vector< A *>::iterator iter;
for ( iter = _objects.begin(); iter != _objects.end(); ++iter )
{
delete (*iter);
}
_objects.clear();
}
A *NewInstance()
{
A *pObject = new A; AddInstance(pObject); return pObject;
}
void DeleteInstance(A *obj)
{
std::vector< A *>::iterator iter;
for ( iter = _objects.begin(); iter != _objects.end(); ++iter )
if ( (*iter) == obj ) _objects.erase(iter);
delete obj;
}
};
class Foo
{
char *s; public:
Foo (void)
{
printf(“Constructor for foo\n”); const char *strTemp = “Hello world”;
s = new char[strlen(strTemp)+1]; strcpy(s, strTemp);
}
Foo( const char *strTemp )
{
printf(“Constructor for foo\n”); s = new char[strlen(strTemp)+1]; strcpy(s, strTemp);
}
Foo( const Foo& aCopy )
{
s = new char[strlen(aCopy.s)+1]; strcpy( s, aCopy.s );
}
virtual ~Foo()
{
printf(“Destructor for foo\n”); delete s;
}
const char *String()
{
return s;
}
void setString( const char *str )
{
if ( s ) delete [] s;
s = new char[strlen(str)+1]; strcpy( s, str );
}
}; |
|
|
int main(void) |
|
|
{ |
6 |
|
Manager<Foo> manager; |
||
Foo *f = manager.NewInstance(); |
|
2 |
Foo *f1 = manager.NewInstance(); |
|
|
Foo *f2 = manager.NewInstance(); |
|
|
Foo *f3 = manager.NewInstance(); |
|
4 |
manager.DeleteInstance( f ); |
|
|
manager.Clean(); |
|
|
return 0;
}
3. Save the source file in your code editor and close the code editor.
178 Technique 30: Creating a Simple Template Class
4. Compile the source code with the compiler of your choice on the operating system of your choice.
Note that when the program is run, if you have done everything properly, you should see the following output in the shell window:
$ ./a.exe |
|
|
Constructor for foo |
|
3 |
Constructor for foo |
|
Constructor for foo
Constructor for foo
Destructor for foo
Destructor for foo
Destructor for foo
Destructor for foo
The output shows us that the constructor is being
called from NewInstance (shown at |
|
2 and then |
|
indicated in the output at 3 |
|
more impor- |
|
|
), but |
|
|
tantly that the destructor is properly invoked when
we call the DeleteInstance method of the manager (shown at 4).
As you can see, the manager does understand the Foo class type, even though we have not actually used the Foo name anywhere in the manager definition. We know this because the manager properly constructs and deletes the objects. How does it do this? Essentially, the template keyword (shown at 5 in the code listing) does all of the work. When the compiler encounters the template keyword, it treats the entire block (in this case, the entire class definition) as if it were a giant “macro” (for lack of a better word). Macros, as you might recall from the ‘C’ preprocessor, substitute a given string for a specific
keyword within the block. Everywhere that the entry in the template (A, in our example) appears within the block, it’s replaced with whatever the template
class is instantiated with (at |
|
6). In our main driver, |
you will see the line: |
|
|
Manager<Foo> manager; |
|
|
This line is expanded by the compiler to replace the A with Foo everywhere that it appears in the template definition. Unlike macros, however, checking is done at the time the instantiation is created, to insure that the code generated is valid C++. For example, had we omitted a copy constructor from the Foo class, it would have generated an error in the use of the Foo class within an STL vector class, because all maneuvering in the vector is done by copying objects from one place to another. You would have seen an error at the line marked 7. The error would have said something about not finding a copy constructor for the class, when the template class vector was expanded by the compiler. For this reason, the compiler first instantiates the entire class, using the class supplied, then compiles the result.
When you are implementing a template class, put all the code inline in a header file. If you don’t, many compilers will only appear to compile the code — but will actually fail in the link phase, since the template instantiation is a one-phase operation. The compiler will not go back and load the code from an external source file.
