Abstracting usage

With creation out of the way, it’s time to tackle the remainder of the design: where the classes are used. Since it’s the act of sorting into bins that’s particularly ugly and exposed, why not take that process and hide it inside a class? This is simple “complexity hiding,” the principle of “If you must do something ugly, at least localize the ugliness.” In an OOP language, the best place to hide complexity is inside a class. Here’s a first cut:

vector<Aluminum*>

TrashSorter vector<Paper*>

vector of

Trash bins

vector<Glass*>

vector<Cardboard*>

A TrashSorter object holds a vector that somehow connects to vectors holding specific types of Trash. The most convenient solution would be a vector<vector<Trash*>>, but it’s too early to tell if that would work out best.

In addition, we’d like to have a sort( ) function as part of the TrashSorter class. But, keeping in mind that the goal is easy addition of new types of Trash, how would the statically-coded sort( ) function deal with the fact that a new type has been added? To solve this, the type information must be removed from sort( ) so all it needs to do is call a generic function which takes care of the details of type. This, of course, is another way to describe a virtual function. So sort( ) will simply move through the vector of Trash bins and call a virtual function for each. I’ll call the function grab(Trash*), so the structure now looks like this:

#include "Trash.h" #include "Aluminum.h" #include "Paper.h" #include "Glass.h" #include "Cardboard.h" #include "fillBin.h" #include "sumValue.h" #include "../purge.h" #include <fstream> #include <vector> using namespace std;

ofstream out("Recycle4.out");

class TBin : public vector<Trash*> { public:

virtual bool grab(Trash*) = 0;

};

template<class TrashType> class TrashBin : public TBin { public:

bool grab(Trash* t) {

TrashType* tp = dynamic_cast<TrashType*>(t); if(!tp) return false; // Not grabbed push_back(tp);

return true; // Object grabbed

}

};

class TrashSorter : public vector<TBin*> { public:

bool sort(Trash* t) {

for(iterator it = begin(); it != end(); it++) if((*it)->grab(t))

return true; return false;

}

void sortBin(vector<Trash*>& bin) { vector<Trash*>::iterator it;

for(it = bin.begin(); it != bin.end(); it++) if(!sort(*it))

cerr << "bin not found" << endl;

}

~TrashSorter() { purge(*this); }

};

int main() { vector<Trash*> bin;

// Fill up the Trash bin: fillBin("Trash.dat", bin); TrashSorter tbins;

tbins.push_back(new TrashBin<Aluminum>); tbins.push_back(new TrashBin<Paper>); tbins.push_back(new TrashBin<Glass>); tbins.push_back(new TrashBin<Cardboard>); tbins.sortBin(bin);

for(TrashSorter::iterator it = tbins.begin(); it != tbins.end(); it++)

sumValue(**it);

sumValue(bin);

purge(bin); } ///:~

TrashSorter needs to call each grab( ) member function and get a different result depending on what type of Trash the current vector is holding. That is, each vector must be aware of the type it holds. This “awareness” is accomplished with a virtual function, the grab( ) function, which thus eliminates at least the outward appearance of the use of RTTI. The implementation of grab( ) does use RTTI, but it’s templatized so as long as you put a new TrashBin in the TrashSorter when you add a type, everything else is taken care of.

Memory is managed by denoting bin as the “master container,” the one responsible for cleanup. With this rule in place, calling purge( ) for bin cleans up all the Trash objects. In addition, TrashSorter assumes that it “owns” the pointers it holds, and cleans up all the TrashBin objects during destruction.