Re: [Quantlib-dev] Extending short-rate models for credit / inflation.

[Luigi B. <lui...@gm...>]

On Mon, 2010-10-25 at 13:20 +0100, Simon Ibbotson wrote:
> That was what I meant (making the classes into template classes ) -
> but it would affect many classes, not just the TSCM and the TSFP.
> Also, any classes that derive from those (e.g. Hull-White, CIR++) and
> that use them (Grids etc.).
> 
> [...]
> 
> Extending the TermStructure definition would be much simpler - or
> adding another layer (e.g. RateBasedTermStructure) which would derive
> from TermStructure and be the base class for YieldTermStructure,
> DefaultProbabilityTermStructure, InflationTermStructure etc.

I'm not sure.  On the one hand, you'd have to modify all the classes
anyway so that they take a RateBasedTermStructure instead of a
YieldTermStructure.  Once you're doing that, you might as well make them
into templates.  On the other hand, RateBasedTermStructure has no
particular concept associated besides "a term structure returning some
kind of rate" or something like that (is default probability a rate?)
which is a bit too generic. It looks to me it would be just an
implementation thing with no actual financial concept behind.

Since the problem you're trying to solve is to unify different
interfaces in some way, have you thought about doing it explicitly and
using an Adapter pattern instead?  Off the top of my head (so I haven't
tested the design to see if there's any showstoppers) you might define
inside the model an inner class like:

class TermStructureConsistentModel {
    ...
  private:
    class OneFactorThingamabob {  // the name is your call
      public:
        virtual ~OneFactorThingamabob() {}
        virtual Real discountOrSomething(Time t) const = 0;
    }

    Handle<OneFactorThingamabob> bob_;
    ...
};


then an adapter like:

template <class T>
class ThingamabobAdapter;

and specializations such as:

template <>
class ThingamabobAdapter<YieldTermStructure>
    : public OneFactorThingamabob {
  public:
    // take and store a YieldTermStructure
    Real discountOrSomething(Time t) const {
        return storedYTS_->discount(t);
    }
};

template <>
class ThingamabobAdapter<DefaultProbabilityTermStructure>
    : public OneFactorThingamabob {
  public:
    // take and store a DefaultProbabilityTermStructure
    Real discountOrSomething(Time t) const {
        return storedYTS_->defaultProbability(t);
    }
};

and finally a template constructor for TSCM:

template <class T>
TermStructureConsistentModel(const Handle<T>& h, ...) {
    bob_ = new ThingamabobAdapter<T>(h);
    ...
}

This should adapt the several interfaces and do the right thing for
each.  It might even remove the need of turning the classes into
templates, since adding templates constructors might suffice.

The problem would be backward compatibility.  But it might (emphasis on
might) be saved by keeping the old constructors as special cases.


Later,
	Luigi



-- 

Brady's First Law of Problem Solving: 
When confronted by a difficult problem, you can solve it more 
easily by reducing it to the question, "How would the Lone 
Ranger have handled this?"