Gotcha #99: Capability Queries

The employee reports to the HR department on his first day of work and is told, "Get in line with the other assets." He's directed to a long line of other employees that also includes, strangely, a variety of office equipment, vehicles, furniture, and legal agreements.

Finally reaching the head of the line, he's assaulted by a sequence of odd questions: "Do you consume gasoline?" "Can you program?" "Can I make copies with you?" Answering "no" to all the questions, he's eventually sent home, wondering why no one thought to ask him if he could mop floors, since that was what he was hired to do.

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."

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.

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.

The employee reports to the HR department on his first day of work. He's directed to a long line of other employees. Finally reaching the head of the line, he's told, "Get to work!" Since he was hired as a janitor, he grabs a mop and spends the rest of the day washing floors.