I have been pondering about this for a few days. Is there a good set of principles to separate market objects such as yield curves, vol surfaces etc from the pricing code. For example, a swap can be constructed knowing the fixed and float leg schedules. When I need to get the pv, I want to say something like1. Get the swap object2. infer market data needed - i.e 6m libor curve and a discount curve3. populate a market container or environment with the objects determined in 2.4. pricing method takes the market container and the swap object to produce the PV.What would be the suitable design pattern for achieving this separation ? Once this is done, we can use various ways to construct the market objects requested in Step 2.

For an inspiration, see http://implementingquantlib.blogspot.com/In particular http://implementingquantlib.blogspot.co ... ook.htmlIn general, though, I'd go easy on the class hierarchies & rigid interfaces.Instead, try not to overengineer nor overconstrain your design.In particular, make sure you can operate on (in terms of inputs & outputs):- arbitrary Callables instead of requiring an object satisfying an assumed interface (say, an existence of a particularly named member function) -- that way you can work with arbitrary function-like variables, including functions and function objects (including (generic) lambdas and forwarding call wrappers generated from std::bind; and, if it turns out you also need run-time type erasure, std::function) -- this will also make writing tests (and you are writing tests, right?) much easier (no / less need for complex setup/teardown boilerplate associated with a more hierarchical OOP approach). In particular, I'd consider a "FixedIncomePricer" requiring a "SwapInstrument" (let alone requiring the "SwapInstrument" to be derived from a "FixedIncomeInstrument", or some other crazyness like that) to be an anti-pattern -- it will make the code unnecessarily rigid, hard to work with (including testing and maintenance) & extend (requiring avoidable boilerplate code is not a development-friendly practice in general; expect significantly higher time-to-market if you go this way).- (almost) arbitrary Container (e.g., SequenceContainer) or an arbitrary Range (e.g., Single Pass Range) instead of any particular "market container"// perhaps soon you'll need to plug-in a time series library to your market data feed -- wouldn't be fun to have to rewrite your pricing engines or constantly copy data if the design assumed an offline data source living in a particular container type, would it?So, "pricing method" itself may as well be a free-standing function (no reason to put this in the class) taking a (refinement of) Callable and a Data (with the Data most likely being a Sequence -- with a refinement being either some kind of Container or a Range).The particular refinement of Callable may nest information on the instrument type (contract sheet -- payoff, maturity, etc.) and required Data (e.g., similarly to the `circumference` example below).See:http://www.generic-programming.org/abou ... zation.php // consider for instance the `circumference` functions family example

For more, I'd recommend watching the following:http://isocpp.org/blog/2013/10/patterns// E.g. consider Strategy (C++11) -- I'd also initially drop the requirement of std::function (read: the requirement of using run-time type erasure) and just take an arbitrary Callable instead (I see no reason to impose the requirement of late / run-time binding without opt-out in general); only use it if you really have to (or it makes important things simpler; e.g., storing std::functions in a container is often the easiest alternative). Design Patterns Are Missing Language Features, so if you're using a language (possibly with accompanying libs) that already has these features, chances are you will need less elaborate workarounds

I think OP might be implementing a design in C#?Then it is a completely different ball-game, especially support for interfaces, (multicast) delegates and assemblies which C++ does not support.Last, but not least, Andrea Germani has a working implementatiion. The basic design can always be improved, even your Gen/Spec angst.

QuoteOriginally posted by: surya2centsI have been pondering about this for a few days. Is there a good set of principles to separate market objects such as yield curves, vol surfaces etc from the pricing code. For example, a swap can be constructed knowing the fixed and float leg schedules. When I need to get the pv, I want to say something like1. Get the swap object2. infer market data needed - i.e 6m libor curve and a discount curve3. populate a market container or environment with the objects determined in 2.4. pricing method takes the market container and the swap object to produce the PV.What would be the suitable design pattern for achieving this separation ? Once this is done, we can use various ways to construct the market objects requested in Step 2.At this stage you might be asking the wrong questions. Some reasons are:1. You do not explicitly state how flexible your software solution shoud be. An answer will determine if and which patterns are needed. And which language (personally, I find C# easier in this case).2. The gap between the above description and patterns is too wide (missing the logical components and provides/requires interfaces.)3. One approach is to desigbn a 'get it working solution' (hard coded) and then generalise it to what you want it to be in the future. In this way you always have a working prototype to show for your efforts.4. First look at the problem in detail, then a solution.In another thread I wrote1. Determine major I/O.2. The steps that link Output to Input in 1. (basically how the algorithms work)3. Find the components and their interfaces that implement the steps in 2.4. Implement 3.5. Test; adapt interfaces if necessary.This is the design approach Structured Analysis (before the OO Enlightenment) and the way mathematicians solve problems. If nothing else, these approaches help you understand the problem.This works in C++ and C# and you can decide at a late stage which kind of language feature to use. Basically, a more precise statement of the problem before jumping into code and patterns is better and saves time in the long term.I have a discussion in the context of MC C#. here

QuoteOriginally posted by: PolterFor more, I'd recommend watching the following:http://isocpp.org/blog/2013/10/patterns// E.g. consider Strategy (C++11) -- I'd also initially drop the requirement of std::function (read: the requirement of using run-time type erasure) and just take an arbitrary Callable instead (I see no reason to impose the requirement of late / run-time binding without opt-out in general); only use it if you really have to (or it makes important things simpler; e.g., storing std::functions in a container is often the easiest alternative). Design Patterns Are Missing Language Features, so if you're using a language (possibly with accompanying libs) that already has these features, chances are you will need less elaborate workarounds :-)Strategy is intrusive and introduces too much coupling. .NET uses embedded deletgates in classes instead.A better approach is to create the data hierarchy and extend it with Visitor. (works very very well).BTW the new juicy features are not yet in C++ 11, so Boost libraries are used instead.

QuoteOriginally posted by: CuchulainnQuoteOriginally posted by: PolterFor more, I'd recommend watching the following:http://isocpp.org/blog/2013/10/patterns// E.g. consider Strategy (C++11) -- I'd also initially drop the requirement of std::function (read: the requirement of using run-time type erasure) and just take an arbitrary Callable instead (I see no reason to impose the requirement of late / run-time binding without opt-out in general); only use it if you really have to (or it makes important things simpler; e.g., storing std::functions in a container is often the easiest alternative). Design Patterns Are Missing Language Features, so if you're using a language (possibly with accompanying libs) that already has these features, chances are you will need less elaborate workarounds :-)Strategy is intrusive and introduces too much coupling. .NET uses embedded deletgates in classes instead.Right. It seems you're illustrating the RestateTheObvious pattern here (very nice! :]) and/or have missed that the "intrusive & too much coupling" point is exactly the criticism made in the link you're attempting to refer to (apparently without applying the RTFA idiom first--how naughty! :]) -- that's why the C++11 version doesn't use the classical strategy pattern, but an uncoupled implementation thereof (relying on polymorphic function wrappers, occasionally called "delegates" by some).Before getting to design patterns, fancy language features, and whatnot, one may want to keep in mind that basic reading comprehension is useful, too // On a serious note, I actually mean it: too often I've seen GoF (mis)applied by an apparent copy-paste without any sign of a deeper consideration given beforehand.

QuoteOriginally posted by: PolterQuoteOriginally posted by: CuchulainnQuoteOriginally posted by: PolterFor more, I'd recommend watching the following:http://isocpp.org/blog/2013/10/patterns// E.g. consider Strategy (C++11) -- I'd also initially drop the requirement of std::function (read: the requirement of using run-time type erasure) and just take an arbitrary Callable instead (I see no reason to impose the requirement of late / run-time binding without opt-out in general); only use it if you really have to (or it makes important things simpler; e.g., storing std::functions in a container is often the easiest alternative). Design Patterns Are Missing Language Features, so if you're using a language (possibly with accompanying libs) that already has these features, chances are you will need less elaborate workarounds :-)Strategy is intrusive and introduces too much coupling. .NET uses embedded deletgates in classes instead.Right. It seems you're illustrating the RestateTheObvious pattern here (very nice! :]) and/or have missed that the "intrusive & too much coupling" point is exactly the criticism made in the link you're attempting to refer to (apparently without applying the RTFA idiom first--how naughty! :]) -- that's why the C++11 version doesn't use the classical strategy pattern, but an uncoupled implementation thereof (relying on polymorphic function wrappers, occasionally called "delegates" by some).Before getting to design patterns, fancy language features, and whatnot, one may want to keep in mind that basic reading comprehension is useful, too // On a serious note, I actually mean it: too often I've seen GoF (mis)applied by an apparent copy-paste without any sign of a deeper consideration given beforehand.Stop playing the angry schoolteacher I use delegates/std function to circumvent (GOF) Strategy. If you use that word then it should refer to GOF Stategy pattern (sory I can't listen to all posted videos). _Cal_ it_something_else_. The new style has been known for at least 6-7 years. So, it's also kinda old hat at this stage. Quoteby an apparent copy-paste without Fire him. Gives GOF a bad name. I have also seen many developers who do do it properly. And at the end of the day who are you (and to a lesser extent, I) to pontificate on what developers should or should not adhere to? It's beginning to sound like a mini-religion.Quotepolymorphic function wrappers, occasionally called "delegates" by some).More precisely, delegate is a keyword in .NET. Compare it to Boost signalsTWO

Polter, Do you have any open source C++ 11 that shows how to solve OP's problem?My own guess is:Either someone has done it (e.g. Katastrofa would be an outside bet) (and why should he tell in that case)orNo one has done it.I suspect the latter.

QuoteOriginally posted by: surya2centsI have been pondering about this for a few days. Is there a good set of principles to separate market objects such as yield curves, vol surfaces etc from the pricing code. For example, a swap can be constructed knowing the fixed and float leg schedules. When I need to get the pv, I want to say something like1. Get the swap object2. infer market data needed - i.e 6m libor curve and a discount curve3. populate a market container or environment with the objects determined in 2.4. pricing method takes the market container and the swap object to produce the PV.What would be the suitable design pattern for achieving this separation ? Once this is done, we can use various ways to construct the market objects requested in Step 2.You've just described how to do it. It's a very simple problem. Just break up your data into two sets: market data and trade data. Match one to the other. Problem solved. It's 101 of implementing a pricing library.

QuoteOriginally posted by: katastrofaQuoteOriginally posted by: surya2centsI have been pondering about this for a few days. Is there a good set of principles to separate market objects such as yield curves, vol surfaces etc from the pricing code. For example, a swap can be constructed knowing the fixed and float leg schedules. When I need to get the pv, I want to say something like1. Get the swap object2. infer market data needed - i.e 6m libor curve and a discount curve3. populate a market container or environment with the objects determined in 2.4. pricing method takes the market container and the swap object to produce the PV.What would be the suitable design pattern for achieving this separation ? Once this is done, we can use various ways to construct the market objects requested in Step 2.You've just described how to do it. It's a very simple problem. Just break up your data into two sets: market data and trade data. Match one to the other. Problem solved. It's 101 of implementing a pricing library.Copy and paste?

If you insist. I wouldn't.

QuoteOriginally posted by: katastrofaIf you insist. I wouldn't.Not even a bit of the old inductive reasoning?

Garbage in, garbage out.

Thanks Cuch, Polter and katastrofa. I have used the links and suggestions below to arrive at a rough plan. But before I proceed further, I need to sort out certain "utility" items such as schedule generation with respect to multiple holiday calendar. I will return to this thread very soon with further thoughts! Raising the holiday calendar point separately.