Re: Design question on virtual methods in QuantLib classes

Posted by Luigi Ballabio on
URL: http://quantlib.414.s1.nabble.com/Design-question-on-virtual-methods-in-QuantLib-classes-tp3955p3956.html

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