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

[Luca B. <bao...@ti...>]

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

Indeed, consider the following simple issue (very common in my code): I w=
ould
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 co=
mpletely
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 QuantL=
ib
> classes
>Date: Thu, 28 Jul 2005 11:01:53 +0100


That=B4s a perfect setting to use the Decorator Design Pattern.



You basically encapsulate a YieldTermStructure QuantLib object as a priva=
te
member of your own MyOwnYieldTermStructureClass and delegate the existing=

functionality with no need for virtual functions nor inheritance. Decorat=
ors
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 c=
lasses.
 

  

Before asking the question I would like to describe my problem. I'm tryin=
g
 

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-keepi=
ng
 

software classes from QuantLib "basic" classes, like e.g. YieldTermStruct=
ure,
 

BlackVolTermStructure, CapVolatilityStructure, and so on. In such a way I=

 

would be able to trasparently use QuantLib classes in the code I write, w=
hen
 

porting my proprietary pricers and models to the bank position-keeping so=
ftware.
 

  

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 c=
lasses
 

as well. Basically the class YieldTermStructure only requires that I writ=
e
 

the discountImpl() method, which take as input a year-fraction. BUT -unfo=
rtunately-
 

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 y=
ear
 

fraction to a date (once the day-counting convention has been specified).=

 

But this is somewhat "inelegant", and also inefficient for day-counters w=
here
 

a direct inversion formula could not be applied.  

  

Neverthless, there could be a simpler approach: if YieldTermStructure met=
hods
 

were all declared as virtual (like it always happens in Java) I could red=
efine
 

in my derived classes all the methods I need to, without worrying about i=
f
 

the inputs I can use are dates or year-fractions. Unfortunately, however,=

 

YieldTermStructure (and many other similar classes) declare as virtual on=
ly
 

discountImpl(), and not the other methods like discount(), zeroRate(), fo=
rwardRate()
 
and so on.  

Is there a rationale for not declaring all the methods in an "abstract" c=
lass
 

-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 Teleco=
m
a partire da  19,95 Euro/mese.
Attivala entro il 28 luglio, il primo MESE =E8 GRATIS! CLICCA QUI.
http://abbonati.tiscali.it/adsl/sa/1e25flat_tc/