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

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