Options inheritance in C#

[Tsotne]

I need opinions...I have created the inheritance chain for options and developed the pricing algorithms for many types. The structure is as follows:

The abstract class "Option" is higher up the inheritance chain defining the common members and polymorphic interface for derived types - properties like underlying, sigma, interestrate, etc. and methods like Price method which is abstract as well and forces the child classes to implement it. The derived classes are divided into the European, American and ExoticOptions classes. European option is the poorer class here which in addition to the inherited members, defines BS formula and the parity relationship as well as some typical characteristics for options. The AmericanOption class defines the some simulation methods and standard binomial pricing function. In addition this class serves as a base class for BermudianOption class which overrides some members but I haven't defined it's pricing models yet. Exotics include the Barrier, Vanila - some Asian option types which override the base class's implementation and extend the functionality by providing their unique version of methods. This was a brief introduction to what I've already done. I plan to make the Derivatives class as the very base class and subclass Option from it in order to have a place for forwards, futures and other derivatives instruments as well. Also want to create a GUI in DevExpress.

So I need your opinions about the structure how it can be done and if you like what is done already.

P.S. I've tried the algorithms to be as fast as possible, made two versions of almost every complex method - one ordinary operating on standard value type variables and the same ones with generics to avoid type conversions for different incoming value types (actually there was no need since it's for my internal use but still - defined two versions of each). Thanks in advance

 

[didje]

I Like your structure! I was planning on create structure like that since the day I started reading the Hull.

You should have done the Derivatives class before to avoid some re-factoring. But the structure looks good since it follows the characteristics of each options.

I don't know if there are interfaces in C# (they exist in Java and you can mock them in C++ with virtual classes containing only strictly virtual methods) but you might use them as well too. It could help you to separate the objects from their behaviours.
If I were you I would stick with the generics. It would allow you later to add new features very easily.

 

[cgorac]

Why not just checking how QuantLib guys built their hierarchy of classes (hint: their Option class has LazyObject as its base class, and inherits directly from Instrument class)?

 

[alain]

check the implementation in Joshi's C++ book. That's another point of view.

 

[didje]

I think that Tsotne didn't check QuantLib's hierarchy on purpose ! He certainly won't re-invent the wheel but he will get a better understanding of what's going on behind.

 

[Tsotne]

You should have done the Derivatives class before to avoid some re-factoring. But the structure looks good since it follows the characteristics of each options.

What do you mean in re-factoring? I have done 4 pure derivatives classes. As for the second part of the sentence, they are logically connected in the chain. All the types are nailed very cleanly, I have gone through many modifications and this is the final structure I ended up with.

I don't know if there are interfaces in C# (they exist in Java and you can mock them in C++ with virtual classes containing only strictly virtual methods) but you might use them as well too. It could help you to separate the objects from their behaviours.

You mean interface type? Of course it exists and it is the integral part of sophisticated inheritance development. In my example, I have defined implied volatility models which I want (and I'm only able...) to include in some derivatives only. So the abstract member is prototyped in interface type named ImpliedVolatility forcing the derived types to implement it.

If I were you I would stick with the generics. It would allow you later to add new features very easily.

That's what I'm doing. I always use generic types especially when dealing with array types.

Thanks for your reply

 

[cgorac]

I think that Tsotne didn't check QuantLib's hierarchy on purpose ! He certainly won't re-invent the wheel but he will get a better understanding of what's going on behind.

I just don't see what sort of deeper understanding could be gained from designing options classes hierarchy - it's not any sort of rocket science and one way or another, you just have to end up with something very similar to what QuantLib guys did, so why bother. I'd say there exist many other places in writing related piece of software that are much more worth the effort.

 

[alain]

I just don't see what sort of deeper understanding could be gained from designing options classes hierarchy - it's not any sort of rocket science and one way or another, you just have to end up with something very similar to what QuantLib guys did, so why bother. I'd say there exist many other places in writing related piece of software that are much more worth the effort.

We have gone over this multiple times. Tsotne wants to reinvent the wheel...or should I say, create a better mouse trap. That's fine as long as he knows that his time might be better spent somewhere else.

 

[Tsotne]

I just don't see what sort of deeper understanding could be gained from designing options classes hierarchy - it's not any sort of rocket science and one way or another, you just have to end up with something very similar to what QuantLib guys did, so why bother. I'd say there exist many other places in writing related piece of software that are much more worth the effort.

Isn't talking to the same wheel boring all the time when I've answered many times that this is for educational purpose? Once answered, so leave your "duplicate" suggestions for yourself! I'm aware of QuantLib in microscopic details thousand more times than you might be.

We have gone over this multiple times. Tsotne wants to reinvent the wheel...or should I say, create a better mouse trap. That's fine as long as he knows that his time might be better spent somewhere else.

Alain I don't need a library which contains some functionality I haven't passed through in details. So my custom made applications sharpens the programming skills and will only include what I feel I want to work with and no more. "Reinventing the wheel" is viewed incorrectly when suggesting everyone to avoid doing the same thing which has already been done. What was your major "contribution" in programming which hadn't been created before? I've seen QuantLib and few similar libraries and I wonder the common usage of their scheme, how close my made is to the widespread practice...

 

[cgorac]

Isn't talking to the same wheel boring all the time when I've answered many times that this is for educational purpose? Once answered, so leave your "duplicate" suggestions for yourself!

My follow-ups to your posts actually are not directed to you - it's pretty much obvious you're quite stubborn in doing things the way you think they should be done, and that's certainly fine with me. However, it is also a fact you're flooding this forum with all kind of opinions and thoughts, and at least regarding programming I can tell you oftentimes these are plain wrong, or misguiding. So I comment from time to time just to counter-balance, for the sake of other people maybe also interested in programming topics, but not knowledgeable enough to separate what is important from what is not.

 

[Tsotne]

With all kinds of opinions and thoughts is nothing wrong as far as it is not proved to be verity. As for stubborn, never have been interested in looking what others have done. When embarking on the library I didn't come up with the idea to initially search for the existing ones to go through and if found better one, then give up. Things are not getting done such if everyone start thinking that what they are going to create has already been done or at least thought about and is not worth doing again.

 

[Daniel Duffy]

Using inheritance is neither necessary nor sufficient for producing 'good' software systems. Class hierarchies tend to be complex, difficult to maintain and sometimes just wrong.

Class hierarchies are context-sensitive and deep ones tend be very unstable.

A system decomposition and information hiding approach is better.