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=
using adapters (or decorators) would not solve many practical problems.
Indeed, consider the following simple issue (very common in my code): I w=
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=
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=
>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=
member of your own MyOwnYieldTermStructureClass and delegate the existing=
functionality with no need for virtual functions nor inheritance. Decorat=
provide a flexible alternative to subclassing for extending functionality=
---------------------- MENSAGEM ORIGINAL ----------------------
I have a question regarding the declaration of some methods in QuantLib c=
Before asking the question I would like to describe my problem. I'm tryin=
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=
software classes from QuantLib "basic" classes, like e.g. YieldTermStruct=
BlackVolTermStructure, CapVolatilityStructure, and so on. In such a way I=
would be able to trasparently use QuantLib classes in the code I write, w=
porting my proprietary pricers and models to the bank position-keeping so=
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=
as well. Basically the class YieldTermStructure only requires that I writ=
the discountImpl() method, which take as input a year-fraction. BUT -unfo=
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=
fraction to a date (once the day-counting convention has been specified).=
But this is somewhat "inelegant", and also inefficient for day-counters w=
a direct inversion formula could not be applied.
Neverthless, there could be a simpler approach: if YieldTermStructure met=
were all declared as virtual (like it always happens in Java) I could red=
in my derived classes all the methods I need to, without worrying about i=
the inputs I can use are dates or year-fractions. Unfortunately, however,=
YieldTermStructure (and many other similar classes) declare as virtual on=
discountImpl(), and not the other methods like discount(), zeroRate(), fo=
and so on.
Is there a rationale for not declaring all the methods in an "abstract" c=
-like YieldTermStructure- as virtual?
Sorry if I was bit long.
Thanks in advance.
TISCALI ADSL 1.25 MEGA
Solo con Tiscali Adsl navighi senza limiti e telefoni senza canone Teleco=
a partire da 19,95 Euro/mese.
Attivala entro il 28 luglio, il primo MESE =E8 GRATIS! CLICCA QUI.