Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Professional C++ [eng].pdf
Скачиваний:
1715
Добавлен:
16.08.2013
Размер:
11.09 Mб
Скачать

Discovering Inheritance Techniques

class DoubleSpreadsheetCell : public SpreadsheetCell

{

public:

DoubleSpreadsheetCell ();

virtual void set(double inDouble);

virtual void set(const std::string& inString);

virtual std::string getString() const;

protected:

static std::string doubleToString(double inValue); static double stringToDouble(const std::string& inValue); double mValue;

};

The implementation of the DoubleSpreadsheetCell is shown here:

DoubleSpreadsheetCell::DoubleSpreadsheetCell() : mValue(-1)

}

}

The set() method that takes a double is straightforward. The string version makes use of the protected static method stringToDouble(). The getString() method converts the stored double value into a string:

void DoubleSpreadsheetCell::set(double inDouble)

{

mValue = inDouble;

}

void DoubleSpreadsheetCell::set(const string& inString)

{

mValue = stringToDouble(inString);

}

string DoubleSpreadsheetCell::getString() const

{

return doubleToString(mValue);

}

You may already see one major advantage of implementing spreadsheet cells in a hierarchy — the code is much simpler. You don’t need to worry about using two fields to represent the two types of data. Each object can be self-centered and only deal with its own functionality.

Note that the implementations of doubleToString() and stringToDouble() were omitted because they are the same as in Chapter 8.

Leveraging Polymorphism

Now that the SpreadsheetCell hierarchy is polymorphic, client code can take advantage of the many benefits that polymorphism has to offer. The following test program explores many of these features.

245

Chapter 10

int main(int argc, char** argv)

{

First, an array of three SpreadsheetCell pointers is declared. Remember that since SpreadsheetCell is an abstract class, you can’t create objects of that type. However, you can still have a pointer or reference to a SpreadsheetCell because it would actually be pointing to one of the subclasses. This array takes advantage of the common type between the two subclasses. Each of the elements of the array could be either a StringSpreadsheetCell or a DoubleSpreadsheetCell. Because they have a common parent, they can be stored together.

SpreadsheetCell* cellArray[3];

The 0th element of the array is set to point to a new StringSpreadsheetCell; the first is also set to a new StringSpreadsheetCell, and the second is a new DoubleSpreadsheetCell.

cellArray[0] = new StringSpreadsheetCell(); cellArray[1] = new StringSpreadsheetCell(); cellArray[2] = new DoubleSpreadsheetCell();

Now that the array contains multityped data, any of the methods declared by the base class can be applied to the objects in the array. The code just uses SpreadsheetCell pointers — the compiler has no idea at compile time what types the objects actually are. However, because they are subclasses of

SpreadsheetCell, they must support the methods of SpreadsheetCell.

cellArray[0]->set(“hello”); cellArray[1]->set(“10”); cellArray[2]->set(“18”);

When the getString() method is called, each object properly returns a string representation of their value. The important, and somewhat amazing, thing to realize is that the different objects do this in different ways. A StringSpreadsheetCell will simply return its stored value. A DoubleSpreadsheetCell will first perform a conversion. As the programmer, you don’t need to know how the object does it — you just need to know that because the object is a SpreadsheetCell, it can perform this behavior.

cout << “Array values are [“ << cellArray[0]->getString() << “,” << cellArray[1]->getString() << “,” <<

cellArray[2]->getString() << “]” << endl;

}

Future Considerations

The new implementation of the SpreadsheetCell hierarchy is certainly an improvement from an object-oriented design point of view. Yet, it would probably not suffice as an actual class hierarchy for a real-world spreadsheet program for several reasons.

First, despite the improved design, one feature of the original is still missing: the ability to convert from one cell type to another. By dividing them into two classes, the cell objects become more loosely integrated. To provide the ability to convert from a DoubleSpreadsheetCell to a StringSpreadsheetCell, you could add a typed constructor. It would have a similar appearance to a copy constructor but instead of a reference to an object of the same class, it would take a reference to an object of a sibling class.

246

Discovering Inheritance Techniques

class StringSpreadsheetCell

{

public:

StringSpreadsheetCell();

StringSpreadsheetCell(const DoubleSpreadsheetCell& inDoubleCell);

...

With a typed constructor, you can easily create a StringSpreadsheetCell given a DoubleSpreadsheetCell. Don’t confuse this with casting, however. Casting from one sibling to another will not work, unless you overload the cast operator as described in Chapter 16.

You can always cast up the hierarchy, and you can sometimes cast down the hierarchy, but you can never cast across the hierarchy unless you have changed the behavior of the cast operator.

The question of how to implement overloaded operators for cells is an interesting one, and there are several possible solutions. One approach is to implement a version of each operator for every combination of cells. With only two subclasses, this is manageable. There would be an operator+ function to add two double cells, to add two string cells, and to add a double cell to a string cell.Another approach is to decide on a common representation. The preceding implementation already standardizes on a string as a common representation of sorts. A single operator+ function could cover all the cases by taking advantage of this common representation. One possible implementation, which assumes that the result of adding two cells is always a string cell, is shown here:

const StringSpreadsheetCell operator+(const StringSpreadsheetCell &lhs, const StringSpreadsheetCell &rhs)

{

StringSpreadsheetCell newCell; newCell.set(lhs.getString() + rhs.getString()); return (newCell);

}

As long as the compiler has a way to turn a particular cell into a StringSpreadsheetCell, the operator will work. Given the previous example of having a StringSpreadsheetCell constructor that takes a DoubleSpreadsheetCell as an argument, the compiler will automatically perform the conversion if it is the only way to get the operator+ to work. That means that the following code will work, even though operator+ was explicitly written to work on StringSpreadsheetCells.

DoubleSpreadsheetCell myDbl;

myDbl.set(8.4);

StringSpreadsheetCell result = myDbl + myDbl;

Of course, the result of this addition won’t really add the numbers together. It will convert the double cell into a string cell and add the strings, resulting in a StringSpreadsheetCell with a value of

8.48.4.

247