I need help modeling the following situation:
A financial instrument always has a price. However, some financial instruments (of certain types, rather) also have what's called "clean" price which is an attribute that depends (among other things) on the price, in which case price is also called "dirty" price. There is a calculator service that computes both the price (or dirty price) and the clean price. How best to conceptually model that situation?
I have considered two alternatives:
FinancialInstrument has a Price
FinancialInstrument
+ price: Price
where Price is a supertype with two derived classes: DirtyPrice and CleanPrice. CleanPrice depends on DirtyPrice
CleanPrice
+ dirty: DirtyPrice
The Calculator service would then compute the price of a FinancialInstrument:
CalculatorService
+ compute_price(FinancialInstrument, ...): Price
FinancialInstrument is a supertype with two derivations: PlainFinancialInstrument (only has on price attribute) and CleanPriceFinancialInstrument that has both clean and dirty prices.
FinancialInstrument
+ price: double
PlainFinancialInstrument CleanPriceFinancialInstrument
+ clean_price: double
The Calculator service would then have two methods to compute price for a PlainSecurity or clean and dirty price for CleanPriceSecurities:
CalculatorService
+ compute_price(PlainFinancialInstrument, ...): double
+ compute_price(CleanPriceFinancialInstrument, ...): pair<double, double>
What are the trade-offs of both alternatives? Are there other alternatives?
Thanks.
it is not clear to me whether you are asking how to model the abstract problem which is specified by means of your example or whether you are trying to model the business concept of financial instrument pricing in a real world context. I think it is the latter, because you are quite specific, so I'll comment on that. In this case I doubt, though, that any of your two approaches is sophisticated enough to meet the needs of your task. I've been working for several years in that area.
I'm not sure which business area you are working in. In the area I used to work in (banking) the difference between clean and dirty price is a simple business concept. Eg for bonds valuated by amortized costs the clean price is the value of the discounted cash flow not taking into account accruals and deferrals, the dirty price is the sum of the clean price and the accruals/deferrals. In all cases known to me the clean price is the difference between dirty price and some most of the times simple functions of some key figures of the financial instrument (FI for short), and both clean and dirty price are just key figures which are relevant for some (but not all) kind of financial instruments.
On the other hand, depending on the GAAP and business area, the question whether you need to supply the clean or dirty price or both may depend in addition on which book the financial instrument is assigned to, eg banking book/trading book. For the trading book you usually want to only retrieve the dirty price, the clean price is relevant in the banking book.
To make things worse a FI may be, e.g., reassigned, leading to a different set of keyfigures becoming relevant. You should make sure your design takes the consequences of such changes into account if this is relevant in your context.
Personally, I'd start on an approach outlined as follows:
create an abstract class/interface for financial instrument
for each type of FI, define a subclass
create a list of all key figures which may become relevant for any possible FI you have in your scope -- in your example: clean price and dirty price, and probably one for the key figure representing the difference. Create a dummy price key figure entry in addition.
for each of these key figures, create a key figure interface with methods relevant for the KFs. E.g. calculate, update -- this depends on your overall model. Again for your example: a clean price interface, a dirty price interface, a delta interface and a price interface. It may become necessary to define an order in which they have to be updated. The set of methods of the price interface has to be a subset of clean and dirty price interface
for each type of FI, create a specific implementation (class) for all the key figure interfaces relevant for that FI type, taking, of course, reuse into account. Strictly avoid if/else or switch statements depending on the key figure or FI types in these implementations, if this turns out to be necessary, you need additional class definitions. Now when you instantiate a class representing an FI, use a factory pattern to create instances of the key figure interfaces. That is, you decide on FI instance creaton which method to use to calculate, the FI instance then knows how to calculate the key figures of the FI. The nice feature of the factory pattern is that you may, additionally take into account the book you are calculating for as well as other parameters, even at run time if necessary. The factory will let the price key figure interface simply point to instance which is relevant in the context.
what you called the calulator service will then, to calculate a price, call a method of the price key figue interface, but the instance that interface points to is provided by the FI instance, because the factory has simply mapped the price interface to the clean price interface or the dirty price interface depending on what is correct for that specific FI in that specific context.
If you use, as suggested, a list of relevant key figures and key figure calculation interface implementations in the FI instance you can even update/exchange this at runtime if the FI is reassigned, without having to delete/recreate the FI instance.
Hope I did not make your question more complex than it actually is.
Regards,
Thomas