Re: Quantlib design

Posted by Luigi Ballabio-3 on Dec 27, 2000; 11:49am
URL: http://quantlib.414.s1.nabble.com/Quantlib-design-tp1657p1664.html

At 11:07 AM 12/27/00 +0100, Ferdinando Ametrano wrote:

>>I may have misunderstood the documentation, but as I read it, I see, for
>>example, "London" to be a subclass of "Calendar". In our project, this would
>>be an instance of Calendar, not a subclass. Same remark for day counts,
>>currencies. We have made extensive use of the design patterns described by
>>the "gang of 4". In particular, we systematically use the factory pattern to
>>instantiate objects. Thus, we have a currencyFactory, calendarFactory, etc.
>This is a good point. As you probably noticed in QuantLib there's a folder
>dedicated to patterns. As of now it contains observable only, but it can grow!

First of all: Nando, shut down that laptop! You're in vacation, for
goodness sake! :)

As for the Calendar thing: indeed London and the other calendars are
Calendar subclasses. This is due to the fact that isBusinessDay() is more
easily implemented as a virtual function. Right now I can't think of
another implementation, apart from adding to Calendar a vector of holidays
to search dates in and having the factory fill it with the right holidays
upon construction. However, this would have a few disadvantages, namely,
a) the calendar instances would be heavier to build and/or pass around. Of
course we could always define a few global instances to refer to.
b) the array would contain holidays up to a certain year, not general rules
for building them.
This actually brings to my mind another implementation in which Calendar
contains a vector of rules. But a structure holding a generic rule (which
could be either "December 25th" or "the first Monday of May" or "January
1st, possibly moved to Monday if it is a Saturday or Sunday") seems to me
to be somehow more complicated than the current implementation.

How did you manage the thing in your implementation?

Furthermore, the implementation of calendars as subclasses does not prevent
using a factory: the latter would simply return a Handle<Calendar> (i.e.,
our smart pointer to the base class) initialized with a pointer to an
instance of the right subclass.

Bye for now,
                 Luigi