[Quantlib-users] Re: Bond class

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

On 04/25/05 05:05:28, Joseph Wang wrote:
> Theo,
> 
> I was looking at your e-mail, and it gave me an idea....  One of the  
> things that you suggested was to create a BondParam class, but I was  
> wondering if it would work better to use aggregation instead of  
> inheiritance, so you'd have something like
> 
> class ConvertibleBond {
>   Bond bond_;
>   ConversionOption option_;
> }

Yes, this is a possibility. But I'm not sure how we should construct  
instances of such a class---passing the two components to the  
ConvertibleBond constructor would result in a two- or three-pass  
initialization, as in:
Bond b(...);
ConversionOption o(...);
ConvertibleBond cb(b, o);
which is a bit verbose (and might require to pass a number of parameters to  
both components) and exposes implementation details.
Passing the set of arguments to the ConvertibleBond constructor and having  
it dispatch them to the components might be more compact.


> One could extend this and just have the conversion option be one type of  
> bond option.  So class bond would have a member which would be a list of  
> BondOption s.
> class Bond {
> (...) current class;
> vector <BondOption> ;
> }
> 
> Thoughts?

I'm not sure that it can be abstracted this way. Having an attached vector  
of options seems to assume that they can be applied independently, or at  
most in the given order, and that one can add their values to obtain the  
value of the instrument. But this is not always the case: for instance, a  
callable convertible bond cannot be modeled as a bond plus two options  
(conversion and callability.) Its value is not
bond + conversion(bond) + callability(bond)
but rather
bond + callability(bond+conversion(bond))
or something like it (since the convertibility affects the value of the  
callability, and the callability can prevent the conversion.) So in general  
there is an interplay between the options whose logic cannot be abstracted  
once and for all.

Later,
	Luigi

----------------------------------------

Humphrey's Requirements Uncertainty Principle:
	For a new software system, the requirements will not be completely
	known until after the users have used it.