| [ Team LiB ] |
|
Gotcha #99: Capability QueriesIn fact, abuse of runtime type information as obvious as that in the terminate function of the previous gotcha is usually the result of compounded hacks and poor project management rather than bad design. However, some "advanced" uses of dynamic casting with multiple inheritance are often pressed into service to form the basis of an architecture.
Sounds a little odd, doesn't it? (Perhaps not, if you've worked for a large corporation.) It should sound odd, because this is an example of improper use of capability queries. Let's leave human resources for a while and head down the hall to finance, to look at a financial instrument hierarchy. Suppose we're trading securities. We have at our disposal a pricing subsystem and a persistence subsystem whose code we'd like to leverage in the implementation of our hierarchy. The requirements of each subsystem are clearly stated in an interface class from which the user of the subsystem must derive:
class Saveable { // persistence interface
public:
virtual ~Saveable();
virtual void save() = 0;
// . . .
};
class Priceable { // pricing interface
public:
virtual ~Priceable();
virtual void price() = 0;
// . . .
};
Some concrete classes of the Deal hierarchy fulfill the subsystem contracts and leverage the subsystem code. This is a standard, effective, and correct use of multiple inheritance:
class Deal {
public:
virtual void validate() = 0;
// . . .
};
class Bond
: public Deal, public Priceable
{/* . . . */};
class Swap
: public Deal, public Priceable, public Saveable
{/* . . . */};
Now we have to add the ability to "process" a deal, given just a pointer to the Deal base class. A naïve approach would simply ask straightforward questions about the object's type, which is no better than our earlier attempt to terminate employees (see Gotcha #98): void processDeal( Deal *d ) { d->validate(); if( Bond *b = dynamic_cast<Bond *>(d) ) b->price(); else if( Swap *s = dynamic_cast<Swap *>(d) ) { s->price(); s->save(); } else throw UnknownDealType( d ); } Another distressingly popular approach is not to ask the object what it is but rather what it can do. This is often called a "capability query": void processDeal( Deal *d ) { d->validate(); if( Priceable *p = dynamic_cast<Priceable *>(d) ) p->price(); if( Saveable *s = dynamic_cast<Saveable *>(d) ) s->save(); } Each base class represents a set of capabilities. A dynamic_cast across the hierarchy, or "cross-cast," is equivalent to asking whether an object can perform a particular function or set of functions, as in Figure 9-15. The second version of processDeal essentially says, "Deal, validate yourself. If you can be priced, price yourself. If you can be saved, save yourself." Figure 9-15. Use of cross-casting to implement capability queries
This approach is a bit more sophisticated than the previous implementation of processDeal. It may also be somewhat less fragile, since it can handle new types of deals without throwing an exception. However, it still suffers from efficiency and maintenance problems. Consider what would happen if a new interface class should appear in the Deal hierarchy, as in Figure 9-16. Figure 9-16. The fragility of capability queries. What if we neglect to ask the right question?
The appearance of a new capability in the hierarchy is not detected. Essentially, the code never thinks to ask if the deal is legal (which, on the other hand, is pretty realistic domain analysis). As with our earlier solution to the problem of terminating an employee, this capability-query-based approach to processing a deal is an ad hoc solution, not a basis for an architecture. The root problem with both identity-based and capability-based queries in object-oriented design is that some of the essential behavior of an object is determined externally to the object itself. This approach runs counter to the principle of data abstraction, perhaps the most basic of the foundations of object-oriented programming. With these approaches, the meaning of an abstract data type is no longer encapsulated within the class used to implement it but is distributed throughout the source code. As with the Employee hierarchy, the safest and most efficient way to add a capability to the Deal hierarchy is also the simplest:
class Deal {
public:
virtual void validate() = 0;
virtual void process() = 0;
// . . .
};
class Bond : public Deal, public Priceable {
public:
void validate();
void price();
void process() {
validate();
price();
}
};
class Swap : public Deal, public Priceable, public Saveable {
public:
void validate();
void price();
void save();
void process() {
validate();
price();
save();
}
};
// etc . . .
Other techniques can be used to improve on the capability query without modifying the hierarchy if the original design makes provision for them. The Visitor pattern allows new capabilities to be added to a hierarchy but is fragile when the hierarchy is maintained. The Acyclic Visitor pattern is less fragile than Visitor but requires a (single) capability query that may fail. Either of these approaches, however, is an improvement over systematic use of capability queries. Generally, the necessity for capability queries is indicative of a bad design, and a simple, efficient, type-safe virtual function call that always succeeds is preferable.
 |
| [ Team LiB ] |
|
