Abstract Factory/Abstract(Virtual) Constructor Pattern

[Plamen Neykov]

Hi All,

I'm relatively new to QuantLib and now I ran into a problem which usually is
resolved via the mentioned patterns - I need to construct a Currency object
from a given ISO three letter code - but I couldn't find any elegant(easy)
method to do this. I was expecting to find some creational pattern available
for all of the "Enum" Classes as for example Currency etc, but as I said I
couldn't find anything - am I overseeing something?

What is the "QuantLib" way to this?

Thanks in advance
Plamen

[Luigi Ballabio]

On 06/01/2005 12:02:33 AM, Plamen Neykov wrote:
>
> I need to construct a Currency object from a given ISO three letter  
> code.
>
> What is the "QuantLib" way to this?

Hi,
        currently there's no "QuantLib way" to do it---I'm not sure  
that class instantiation based on textual input falls into the scope of  
a library. However, as Currency instances are stateless, you might use  
a prototype pattern; the simplest way would be something like:

std::map<std::string, Currency> knownCurrencies;

void initializeCurrencyMap() {
     knownCurrencies["EUR"] = EURCurrency();
     knownCurrencies["GBP"] = GBPCurrency();
     knownCurrencies["USD"] = USDCurrency();
     ...
}

you'll have to call the initialization procedure explicitly, after  
which you can write:

void foo(const std::string& iso, ...) {
     ...
     Currency c = knownCurrencies[iso];
     ...
}

A possible development would be to encapsulate the map in a singleton;  
this would give you the possibility of calling the initialization  
procedure automatically when the singleton is first accessed.

HTH,
        Luigi


----------------------------------------

Newton's Law of Gravitation:
        What goes up must come down.  But don't expect it to come down
        where you can find it.  Murphy's Law applies to Newton's.

[Plamen Neykov]

Hi Luigi,

> currently there's no "QuantLib way" to do it---I'm not sure
> that class instantiation based on textual input falls into the scope of
> a library. However, as Currency instances are stateless, you might use
> a prototype pattern; the simplest way would be something like:

I was thinking more about using the following pattern (or at least some parts
of it, like the class registration mechanism):
http://www.cs.wustl.edu/~schmidt/europlop-96/papers/paper26.ps

It could be that a more generic mechanism would also be usefull for other
classes as for example the family of the DayCounter derived classes.

>
> std::map<std::string, Currency> knownCurrencies;
>
> void initializeCurrencyMap() {
>      knownCurrencies["EUR"] = EURCurrency();
>      knownCurrencies["GBP"] = GBPCurrency();
>      knownCurrencies["USD"] = USDCurrency();
>      ...
> }
>
> you'll have to call the initialization procedure explicitly, after
> which you can write:
>
> void foo(const std::string& iso, ...) {
>      ...
>      Currency c = knownCurrencies[iso];
>      ...
> }
>
> A possible development would be to encapsulate the map in a singleton;
> this would give you the possibility of calling the initialization
> procedure automatically when the singleton is first accessed.

Sure - as you said, if this stuff is out of the Library's scope, I'll take the
approach you suggested.

Thanks,
Plamen

[Luigi Ballabio]

On 06/01/2005 05:07:29 PM, Plamen Neykov wrote:
>
> I was thinking more about using the following pattern (or at least
> some parts of it, like the class registration mechanism):
> http://www.cs.wustl.edu/~schmidt/europlop-96/papers/paper26.ps

I see. Hmm, I don't think this is in the scope of a  
library---especially since one can't know how it will be used (shared  
library, statically linked...)

However, it could be in the scope of the ObjectHandler thing Eric  
Ehlers is developing. Eric, any comments?

Later,
        Luigi

----------------------------------------

There are two ways to write error-free programs; only the third one  
works.
-- unknown

[Plamen Neykov]

Hi Luigi,

thanks for the answer - actually I've followed your advice and created a
singleton class which does the creation - via a map<...> I'm attaching here
the source just for your info - I also think it is really better placed in
the QuantLibAddin ..... I'll take this to Eric.

Thanks,
Plamen

P.S. I've attached the files with the hope that some one will make some
comments and suggestions  ;-)

P.P.S. If someone wonders how it is used here an example:
QuantLib::Currency crr =
EnumTypeFactory::instance().create<QuantLib::Currency>(crrID);

QuantLib::Compounding comp =
EnumTypeFactory::instance().create<QuantLib::Compounding>(compounding)


On Friday 03 June 2005 11:15, Luigi Ballabio wrote:

> On 06/01/2005 05:07:29 PM, Plamen Neykov wrote:
> > I was thinking more about using the following pattern (or at least
> > some parts of it, like the class registration mechanism):
> > http://www.cs.wustl.edu/~schmidt/europlop-96/papers/paper26.ps
>
> I see. Hmm, I don't think this is in the scope of a
> library---especially since one can't know how it will be used (shared
> library, statically linked...)
>
> However, it could be in the scope of the ObjectHandler thing Eric
> Ehlers is developing. Eric, any comments?
>
> Later,
> Luigi
>
> ----------------------------------------
>
> There are two ways to write error-free programs; only the third one
> works.
> -- unknown

[eric ehlers]

Hello

On 6/3/05, Luigi Ballabio <[hidden email]> wrote:

>
> On 06/01/2005 05:07:29 PM, Plamen Neykov wrote:
> >
> > I was thinking more about using the following pattern (or at least
> > some parts of it, like the class registration mechanism):
> > http://www.cs.wustl.edu/~schmidt/europlop-96/papers/paper26.ps
>
> I see. Hmm, I don't think this is in the scope of a
> library---especially since one can't know how it will be used (shared
> library, statically linked...)
>
> However, it could be in the scope of the ObjectHandler thing Eric
> Ehlers is developing. Eric, any comments?

QuantLibAddin currently supports rudimentary mapping of strings to
classes e.g. the option constructor accepts "PUT" to indicate
QuantLib::Option::Put.

The abstract constructor pattern might be impractical because it
requires that additional code be embedded into the classes you want to
create, the prototype pattern (e.g. singleton/map) seems cleaner ...

On 6/3/05, Plamen Neykov <[hidden email]> wrote:
>
> thanks for the answer - actually I've followed your advice and created a
> singleton class which does the creation - via a map<...> I'm attaching here
> the source just for your info - I also think it is really better placed in
> the QuantLibAddin ..... I'll take this to Eric.

... at first glance this looks like a vast improvement on the existing
approach, I'll look at it in more detail and confirm.

Regards,
Eric