Re: [Boost-users] Library Interface Design

From: Joel de Guzman (joel_at_[hidden])
Date: 2006-09-14 04:21:24

Scott Meyers wrote:
> 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.

How many Ts (for all EventLog<T>) do you need? For deployment in an
application, surely the set of Ts is bounded. If there is a need to
put them in a container, I'd place them in a tuple or a fusion::set,
or if you have more than one instances of each, a tuple or a fusion::set
of std::vector(s).

Regards,
-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net