Re: [Quantlib-dev] Design question on virtual methods in QuantLib classes

[Luca Berardi]

Actually I would prefer to avoid the use of any adapter classes (and the
Decorator design pattern certainly falls into this category). This is because
using adapters (or decorators) would not solve many practical problems.

Indeed, consider the following simple issue (very common in my code): I would
like to create an instance of a Xibor object so I would need -among other
inputs- an object of type Handle<YieldTermStructure>. Now I can't clearly
use an object of type Handle<MyOwnYieldTermStructureClass>, as it is a completely
different type. You can see that in such cases the use of Decorators (or
more generally adapters) can't  really help.



>-- Messaggio Originale --
>Subject: Re: [Quantlib-dev] Design question on virtual methods in QuantLib
> classes
>Date: Thu, 28 Jul 2005 11:01:53 +0100


That´s a perfect setting to use the Decorator Design Pattern.



You basically encapsulate a YieldTermStructure QuantLib object as a private
member of your own MyOwnYieldTermStructureClass and delegate the existing
functionality with no need for virtual functions nor inheritance. Decorators
provide a flexible alternative to subclassing for extending functionality.



---------------------- MENSAGEM ORIGINAL ----------------------



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/