Hi,
Looking at the strata code, I am trying to understand why there is a complex trade hierarchy that mimics the product hierarchy instead of something similar to position ? What is the rationale for that?
thanks in advance
Hi,
Looking at the strata code, I am trying to understand why there is a complex trade hierarchy that mimics the product hierarchy instead of something similar to position ? What is the rationale for that?
thanks in advance
Sorry forgot to mention that I have the same question with regards to the Resolved hierarchy which could have been simplified.
We took the view that we wanted real code with documented fields for the product hierarchy, such as Fra
and Swap
. We investigated using generics for the trade level, eg OtcTrade<Fra>
but found that it made significant areas of the code more complex. In particular, we switch based on the type of the trade class within the strata-calc
module, and this was much harder to do if using a generified trade.
The resolved classes are similar to the main classes, but each one tends to have some differences. In essence they represent the view of the trade/product that is needed for analytics, with the date calculations already performed (like schedule expansion). Again, because we wanted to have real classes with real documentation, this design made sense to us.