[Somelib] PROPOSAL: Enforcing factory pattern usage in SOMELib

[John P. <jo...@ma...>]

I have just been reading an awsome book (Dessign Patterns; Eric Gamma,
Richard Helm, Ralf Johnson, John Vlissides : Addison-Wesley:1995).  It
describes the use of Factories to abstract the initilization of
objects.  Factories take a group of similar objects and encapsulates
them with itself.  (In essence each SOMELib object is a factory with
only one object and SOMELib itself is a factory of all other objects)
The advantages to this in a plugin system is to allow for the user of
the plugin to use the SOMELib factory to obtain a refrence to a specific

factory object and then use that factory's interface to produce an
object that the user needs without the user needing to know the specific

object they are implementing.  Here is an example:

Say I write a graphics viewing plugin.  Well I could write a seperate
SOMEObject for each graphics type or I could write a factory that
exports the method getGraphics( string filename); and group all my
graphics objects (jpg, png, tiff, 3ds, etc.) into that factory.  The
factory would then load the apropriate object and pass it to the user.

The benefits are twofold, first it helps plugin writers to write more
reusible and better orginized code and second patterns are so well
documented(the STL is just a collection of objects based on patterns)
that most C++ programmers will see them and say, "ahhh, now
I understand".  Therefor I propose that all documentation and examples
should be written using the Factory pattern to facilitate understanding
and encourage users of SOMELib to follow our example.  Also, once again
messing with the namespace, the SOMELib object should me renamed to
SOMELibFactory and the initilization method should be changed to
getFactory( string factoryname ) or obtainFactoryRef( string
factoryname ).

Please comment.

-John Palmieri(Quinticent)