Re: [Boost-users] Library Interface Design

From: Scott Meyers (usenet_at_[hidden])
Date: 2006-09-14 01:17:36

Joel de Guzman wrote:
> One-phase construction definitely! Testing in isolation is a different
> matter and should not degrade the interfaces. There are ways to allow
> isolated testing without degrading the interface. It all boils down
> to decoupling and isolating dependencies. My favorites:
> 
> 1) Use a template where policies can be replaced by hooks to the
>     testing engine that tests the expected results. In your example,
>     I'd imagine this interface: template <class Printer> EventLog.

Or the more conventional OO approach of subclassing from ostream (in the 
example) and passing in a null or mock derived class object for testing 
purposes.

Your approach has the drawback that it's now more difficult to have a 
container of all EventLog objects (because Printer is part of the type) 
and the OO approach has the drawback of requiring the introduction of a 
base class and virtuals in cases where they might otherwise not be 
necessary.  To modify the example, suppose the EventLog constructor 
requires a Widget, and Widget is a large nonpolymorphic object with no 
virtuals.  I'd still pass the Widget by reference, but subclassing it 
for testing would be ineffective, due to the lack of virtuals.

Either way the desire to make the class testable affects the interface 
seen by users.  This is not a complaint, just an observation.  In 
another post, I noted that it seems like it'd be nice to be able to 
somehow create a "testing only" interface separate from the "normal" 
client interface.

> 2) Use callbacks. In the example you provided, I'd imagine EventLog
>     calls logstream to print. So, I'd use a constructor like:
>     EventLog::EventLog(boost::function<void(std::string const&)> print)
>     instead. So, instead of calling logstream << stuff directly,
>     I'll call print(stuff). For the testing engine, I'll replace it
>     with something that tests the expected results.
> 
> All these falls under the "Hollywood Principle: Don't call us,
> we'll call you". IMO, with proper design, you can have both single
> phase construction *and* isolation testing.

But can you also have maximal inlining and, where needed by clients, 
runtime polymorphism?  Templates preserve inlining but tend to sacrifice 
polymorphism (e.g., it's hard to have a container of (smart) pointers to 
EventLog<T> objects for all possible Ts), while base class interfaces 
and callbacks preserve polymorphism at the expense of easy inlining.

Scott