Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Extendable factory
59 views
Skip to first unread message
Mark
May 29, 2012, 6:03:54 AM5/29/12
to
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.
--
(\__/) M.
(='.'=) If a man stands in a forest and no woman is around
(")_(") is he still wrong?
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.
--
(\__/) M.
(='.'=) If a man stands in a forest and no woman is around
(")_(") is he still wrong?
Luca Risolia
May 29, 2012, 7:02:45 AM5/29/12
to
On 29/05/2012 12:03, Mark wrote:
> 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:
> 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.
Abstract Factory, Builder, Prototype just to name a few. Look at "Design
Patterns" by GoF for more informations.
nick_keigh...@hotmail.com
May 29, 2012, 8:08:28 AM5/29/12
to y5oj...@sneakemail.com
On Tuesday, May 29, 2012 11:03:54 AM UTC+1, Mark wrote:
> 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.
> 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.
Mark
May 29, 2012, 10:32:19 AM5/29/12
to
special kind of Factory Method -- where it can create any derived
class. Builders, Abstract Factories, Prototypes are for different
purposes.
Luca Risolia
May 29, 2012, 11:03:55 AM5/29/12
to
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
> 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.
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
May 30, 2012, 4:51:55 AM5/30/12
to
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
May 30, 2012, 5:09:02 AM5/30/12
to
On 05/30/12 08:51 PM, Mark wrote:
Some books never date.
--
Ian Collins
> On Tue, 29 May 2012 17:03:55 +0200, Luca Risolia wrote:
>>
>> 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?
It'll only be out of date if and when there's a new edition!
>>
>> 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?
Some books never date.
--
Ian Collins
Mark
May 30, 2012, 5:35:19 AM5/30/12
to
On Wed, 30 May 2012 21:09:02 +1200, Ian Collins <ian-...@hotmail.com>
wrote:
But hasn't C++ changed quite a bit since the last edition?
wrote:
Ian Collins
May 30, 2012, 5:51:05 AM5/30/12
to
On 05/30/12 09:35 PM, Mark wrote:
> On Wed, 30 May 2012 21:09:02 +1200, Ian Collins<ian-...@hotmail.com>
> wrote:
>
>> On 05/30/12 08:51 PM, Mark wrote:
>>> On Tue, 29 May 2012 17:03:55 +0200, Luca Risolia wrote:
>>>>
>>>> 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?
>>
>> 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?
The language may have been through a revision, but the fundamentals
> On Wed, 30 May 2012 21:09:02 +1200, Ian Collins<ian-...@hotmail.com>
> wrote:
>
>> On 05/30/12 08:51 PM, Mark wrote:
>>> On Tue, 29 May 2012 17:03:55 +0200, Luca Risolia wrote:
>>>>
>>>> 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?
>>
>> 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?
remain the same.
--
Ian Collins
nick_keigh...@hotmail.com
May 30, 2012, 8:35:23 AM5/30/12
to
On Wednesday, May 30, 2012 10:09:02 AM UTC+1, Ian Collins wrote:
> On 05/30/12 08:51 PM, Mark wrote:
> > On Tue, 29 May 2012 17:03:55 +0200, Luca Risolia wrote:
> >> 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?
>
> 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!
> On 05/30/12 08:51 PM, Mark wrote:
> > On Tue, 29 May 2012 17:03:55 +0200, Luca Risolia wrote:
> >> 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?
>
> It'll only be out of date if and when there's a new edition!
> Some books never date.
you obviously weren't around whrn C++ was new!
Ian Collins
May 30, 2012, 3:36:31 PM5/30/12
to
On 05/31/12 12:35 AM, nick_keigh...@hotmail.com wrote:
> On Wednesday, May 30, 2012 10:09:02 AM UTC+1, Ian Collins wrote:
>> On 05/30/12 08:51 PM, Mark wrote:
>>> On Tue, 29 May 2012 17:03:55 +0200, Luca Risolia wrote:
>
>>>> 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?
>>
>> 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!
That's way I said they go out of date when replaced.
> On Wednesday, May 30, 2012 10:09:02 AM UTC+1, Ian Collins wrote:
>> On 05/30/12 08:51 PM, Mark wrote:
>>> On Tue, 29 May 2012 17:03:55 +0200, Luca Risolia wrote:
>
>>>> 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?
>>
>> 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
Scott Lurndal
May 30, 2012, 4:15:57 PM5/30/12
to
the USL distribution floppy for the cfront 2.1 sources.
scott
Mark
May 31, 2012, 6:04:22 AM5/31/12
to
look at it, please?
Mark
May 31, 2012, 8:37:48 AM5/31/12
to
On Thu, 31 May 2012 11:04:22 +0100, Mark
I've solved it now so no need to worry. Thanks for the help.
0 new messages