Extendable factory

[Mark]

I wish to develop an extendable object factory for a library I am
writing. The library is to provide a simplified interface to a
messaging application. Most of the work is done within the library
but the user has to override a class and provide the implementation to
a single virtual function (to read data).

It's easy to provide factory methods for the built in classes but I am
struggling to think how to provide a factory method for classes that
are added later.

I know I could allow them to create the objects directly but I would
rather avoid this because it would expose some unneccessary details of
the implementation of the library itself.

 

[Luca Risolia]

I wish to develop an extendable object factory for a library I am
writing. The library is to provide a simplified interface to a
messaging application. Most of the work is done within the library
but the user has to override a class and provide the implementation to
a single virtual function (to read data).

It's easy to provide factory methods for the built in classes but I am
struggling to think how to provide a factory method for classes that
are added later.

I know I could allow them to create the objects directly but I would
rather avoid this because it would expose some unneccessary details of
the implementation of the library itself.

There exist various creational patterns other than the Factory Method:
Abstract Factory, Builder, Prototype just to name a few. Look at "Design
Patterns" by GoF for more informations.

 

[Guest]

I wish to develop an extendable object factory for a library I am
writing. The library is to provide a simplified interface to a
messaging application. Most of the work is done within the library
but the user has to override a class and provide the implementation to
a single virtual function (to read data).

It's easy to provide factory methods for the built in classes but I am
struggling to think how to provide a factory method for classes that
are added later.

I know I could allow them to create the objects directly but I would
rather avoid this because it would expose some unneccessary details of
the implementation of the library itself.

have the new classes register themselves with the factory and provide a static method the factory can call to create them. Another way is to have objects clone themselves.

 

[Mark]

There exist various creational patterns other than the Factory Method:
Abstract Factory, Builder, Prototype just to name a few. Look at "Design
Patterns" by GoF for more informations.

I've seen many examples of these. From what I can see I need a
special kind of Factory Method -- where it can create any derived
class. Builders, Abstract Factories, Prototypes are for different
purposes.

 

[Luca Risolia]

I've seen many examples of these. From what I can see I need a
special kind of Factory Method -- where it can create any derived
class. Builders, Abstract Factories, Prototypes are for different
purposes.

One way is to register your factories (pointers to function) in a map
that you give to the user, i.e. :

shapes["circle"] = Circle::create; // registration
shapes["triangle"] = Triangle::create;

Shape* s = shapes["circle"](); // creation

f(s); // use

where f() might be:

void f(Shape* s) { // accept any shape
s->rotate() // rotate() is virtual
}

See Stroustrup "The C++ Programming Language", chapter 25 for more
informations. Look this to have an idea:

http://www.linux-projects.org/listing/cpp_solutions/25.1/main.cpp

 

[Mark]

I've seen many examples of these. From what I can see I need a
special kind of Factory Method -- where it can create any derived
class. Builders, Abstract Factories, Prototypes are for different
purposes.

One way is to register your factories (pointers to function) in a map
that you give to the user, i.e. :

shapes["circle"] = Circle::create; // registration
shapes["triangle"] = Triangle::create;

Shape* s = shapes["circle"](); // creation

f(s); // use

where f() might be:

void f(Shape* s) { // accept any shape
s->rotate() // rotate() is virtual
}

See Stroustrup "The C++ Programming Language", chapter 25 for more
informations. Look this to have an idea:

Our copy of Stroustrup dissappeared long ago. Wouldn't it be out of
date anyway now?

http://www.linux-projects.org/listing/cpp_solutions/25.1/main.cpp

Thanks for this. I think I can adapt this approach. Please keep
watching this thread though

 

[Ian Collins]

Our copy of Stroustrup dissappeared long ago. Wouldn't it be out of
date anyway now?

It'll only be out of date if and when there's a new edition!

Some books never date.

 

[Mark]

It'll only be out of date if and when there's a new edition!

Some books never date.

But hasn't C++ changed quite a bit since the last edition?

 

[Ian Collins]

But hasn't C++ changed quite a bit since the last edition?

The language may have been through a revision, but the fundamentals
remain the same.

 

[Guest]

It'll only be out of date if and when there's a new edition!

editions 1 and 2 are out of date. Ed 1 is almost dangerous!

Some books never date.

you obviously weren't around whrn C++ was new!

 

[Ian Collins]

editions 1 and 2 are out of date. Ed 1 is almost dangerous!

That's way I said they go out of date when replaced.

you obviously weren't around whrn C++ was new!

Oh but I was, I still a have full set of Stroustrups!

 

[Mark]

I've seen many examples of these. From what I can see I need a
special kind of Factory Method -- where it can create any derived
class. Builders, Abstract Factories, Prototypes are for different
purposes.

One way is to register your factories (pointers to function) in a map
that you give to the user, i.e. :

shapes["circle"] = Circle::create; // registration
shapes["triangle"] = Triangle::create;

Shape* s = shapes["circle"](); // creation

f(s); // use

where f() might be:

void f(Shape* s) { // accept any shape
s->rotate() // rotate() is virtual
}

See Stroustrup "The C++ Programming Language", chapter 25 for more
informations. Look this to have an idea:

Our copy of Stroustrup dissappeared long ago. Wouldn't it be out of
date anyway now?

http://www.linux-projects.org/listing/cpp_solutions/25.1/main.cpp

Thanks for this. I think I can adapt this approach. Please keep
watching this thread though

I'm still struggling with this. If I create an example can someone
look at it, please?

 

[Mark]

On 29/05/2012 16:32, Mark wrote:
I've seen many examples of these. From what I can see I need a
special kind of Factory Method -- where it can create any derived
class. Builders, Abstract Factories, Prototypes are for different
purposes.

One way is to register your factories (pointers to function) in a map
that you give to the user, i.e. :

shapes["circle"] = Circle::create; // registration
shapes["triangle"] = Triangle::create;

Shape* s = shapes["circle"](); // creation

f(s); // use

where f() might be:

void f(Shape* s) { // accept any shape
s->rotate() // rotate() is virtual
}

See Stroustrup "The C++ Programming Language", chapter 25 for more
informations. Look this to have an idea:

Our copy of Stroustrup dissappeared long ago. Wouldn't it be out of
date anyway now?

http://www.linux-projects.org/listing/cpp_solutions/25.1/main.cpp

Thanks for this. I think I can adapt this approach. Please keep
watching this thread though

I'm still struggling with this. If I create an example can someone
look at it, please?

I've solved it now so no need to worry. Thanks for the help.