Design question on virtual methods in QuantLib classes

[Luca Berardi]

Hi all

I have a question regarding the declaration of some methods in QuantLib classes.

Before asking the question I would like to describe my problem. I'm trying
to integrate my QuantLib-based pricers and models in the position-keeping
software being used in the bank where I work.

This is what I would like to do: I would like to derive my position-keeping
software classes from QuantLib "basic" classes, like e.g. YieldTermStructure,
BlackVolTermStructure, CapVolatilityStructure, and so on. In such a way I
would be able to trasparently use QuantLib classes in the code I write, when
porting my proprietary pricers and models to the bank position-keeping software.

But there is a problem in doing so: I would take as an example the class
YieldTermStructure, yet the same issue could go for many other QuantLib classes
as well. Basically the class YieldTermStructure only requires that I write
the discountImpl() method, which take as input a year-fraction. BUT -unfortunately-
the position-keeping software APIs only allow to compute discount factors
using dates (not year-fractions) as inputs.
I have temporarily solved this issue by writing a function converting a year
fraction to a date (once the day-counting convention has been specified).
But this is somewhat "inelegant", and also inefficient for day-counters where
a direct inversion formula could not be applied.

Neverthless, there could be a simpler approach: if YieldTermStructure methods
were all declared as virtual (like it always happens in Java) I could redefine
in my derived classes all the methods I need to, without worrying about if
the inputs I can use are dates or year-fractions. Unfortunately, however,
YieldTermStructure (and many other similar classes) declare as virtual only
discountImpl(), and not the other methods like discount(), zeroRate(), forwardRate()
and so on.
Is there a rationale for not declaring all the methods in an "abstract" class
-like YieldTermStructure- as virtual?

Sorry if I was bit long.
Thanks in advance.

Luca





__________________________________________________________________
TISCALI ADSL 1.25 MEGA
Solo con Tiscali Adsl navighi senza limiti e telefoni senza canone Telecom
a partire da  19,95 Euro/mese.
Attivala entro il 28 luglio, il primo MESE è GRATIS! CLICCA QUI.
http://abbonati.tiscali.it/adsl/sa/1e25flat_tc/

[Luigi Ballabio]

On 07/28/2005 10:57:37 AM, Luca Berardi wrote:

> This is what I would like to do: I would like to derive my
> position-keeping software classes from QuantLib "basic" classes, like  
> e.g. YieldTermStructure, BlackVolTermStructure,  
> CapVolatilityStructure, and so on. In such a way I would be able to  
> trasparently use QuantLib classes in the code I write, when
> porting my proprietary pricers and models to the bank  
> position-keeping software.
>
> But there is a problem in doing so: [...] the class  
> YieldTermStructure only requires that I write the discountImpl()  
> method, which take as input a year-fraction. BUT -unfortunately- the  
> position-keeping software APIs only allow to compute discount factors  
> using dates (not year-fractions) as inputs.
>
> [...] if YieldTermStructure methods were all declared as virtual  
> (like it always happens in Java) I could redefine in my derived  
> classes all the methods I need to, without worrying about if
> the inputs I can use are dates or year-fractions. Unfortunately,
> however, YieldTermStructure (and many other similar classes) declare  
> as virtual only discountImpl(), and not the other methods like  
> discount(), zeroRate(), forwardRate() and so on.
>
> Is there a rationale for not declaring all the methods in an
> "abstract" class -like YieldTermStructure- as virtual?

Luca,
        it's the standard way the Template Method pattern is  
implemented (see e.g. the GOF book.) Also, at the time it seemed that  
there were no need for such methods to be virtual, so we didn't declare  
them so (we're usually conservative when declaring methods, the reason  
being that while it is often possible to make a non-virtual method  
virtual without breaking a lot of existing code, the opposite  
change---should we find it necessary---would certainly break it.)

Therefore, I think you can go ahead, declare the methods you need as  
virtual, recompile and see what happens. If the test-suite doesn't  
break and your system works, get back to me and I'll make the change in  
the repository.

Later,
        Luigi

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

Everything can be filed under "miscellaneous".
-- unknown