Re: [Boost-users] [review] Formal Fast-Track review of the Boost.Functional/Factory library - 2 days left

From: Nat Goodspeed (nat_at_[hidden])
Date: 2007-12-21 12:08:07

Tobias Schwinger wrote:

> We have to keep in mind that the GoF book was written more than a 
> decade ago. The abstract definitions of Design Patterns are pretty much 
> timeless, however, the implementations in today's C++ can look different 
> - even incomplete (details below).

>> I used the library to build a toy version of a Factory mechanism from a 
>> previous project. With that, the client passes a std::string name and 
>> gets a pointer to the corresponding concrete implementation of an 
>> abstract base class.

> If we want to create derived classes from an abstract base, 
> boost::function needed. But is this isn't the only way to implement the 
> Factory Patterns, is it?
> 
> If we want to create just objects that fulfill a certain concept we 
> don't need boost::function at all. Note that the Patterns' definitions 
> still hold - it just isn't all spelled out; the concept is not 
> formalized in the programming language and so the need for a Factory 
> base class and the implicit upcast of the Product vanishes as well.
> 
> So, it pretty much comes down to that OOD Patterns look different when 
> they're applied at generic level. Also note we're not tied to class 
> level granularity anymore, e.g:
> 
>      class some_class
>      {
>          // ...
> 
>          // Observer Pattern (all what's left of it):
>          void register_observer(function<void()> observer_function);
>      };
> 
> It's much nicer than the traditional GoF code, isn't it? We have both 
> eliminated the coupling and the boilerplate code!

I'm willing to concede that I may be burdened with outdated notions of 
how to solve such problems. I would be very interested to know how I 
should do it better.

The issue I mentioned above keeps recurring across different projects: 
given a string from a file or a script, I need to instantiate a distinct 
C++ class corresponding to that string. I mention an abstract base class 
because I don't know how, other than virtual functions, I should access 
the features of such an object.

I would dearly love to see the best way to leverage boost::factory to 
address this problem. If, in the process, I learn new tricks myself, all 
the better!

Perhaps the library is more squarely targeting a whole family of 
real-world problems that I haven't yet encountered. I wouldn't mind 
being educated about those use cases, either.

You see where I'm going with this. More examples would really help -- 
not just when trying to use the library, but even to decide whether this 
library can help me solve the problem at hand.

>> My one concern is that perhaps the name boost::factory should be 
>> reserved for a later, more full-featured library, built on this one -- 
>> though I haven't yet thought of a more descriptive name for this one 
>> that's both clear and concise.

> My personal feeling towards a more full-featured 'boost::factory' is 
> that it will be either overly simplified or a tool to break a butterfly 
> on a policy-based wheel...

Heh. I hope my remarks about the name boost::factory didn't come across 
as arrogant or condescending. If so, profuse apologies!

It may well be that the library, just as it stands, is far more powerful 
than I have yet realized. Again, I'd love to be enlightened about other 
use cases. Thanks.