Daniel Duffy

Design Patterns and C++

for Option Pricing Part 1
What are patterns and why ing member data and member functions operat-
Some examples of modifications and the ensu-
ing on that data. When you wrote the code for
do we need them? the class you probably thought it was pretty cool ing problems are:
and flexible. A few weeks later your manager 1. It must be possible to initialise the data in an
strolls into the room with a new list of require- option from an XML file, from an Oracle data-
ments that force you in fact to do a complete base, from a dialog box or any other data source

T
his is the first article in a series of
rewrite of the code! For example, let us take a in the future without having to reedit our code.
three on design patterns for finan-
simple example of a C++ class that models In other words, instead of the usual hard-coded
cial engineering applications. In
options (see Duffy 2003, 2003a). The class header constructors we would like, in some magical
this article we give an introduction
file looks something like: way to define virtual constructors that protect
to what design patterns are, why
client code from the specific code for creating
they are important and how they
class EuropeanOption objects.
are used in financial engineering applications.
{ 2. We would like to define a prototypical object
In the second article we shall discuss design
private: that contains default data. Client code can then
patterns in more detail (using Gamma 1995 as
create objects as clones of this prototype and can
the standard text) and we show how to apply
double r; // Interest rate then change the values of member data as
these so-called Gang-Of-Four (GOF) patterns to a
double sig; // Volatility desired. This is similar in a GUI environment
number of instrument pricing problems (as dis-
double K; // Strike price where we can drag a control object (for example,
cussed in Duffy 2004a). Finally, in the third arti-
double T; // Expiry date a command button) to the working canvas and
cle we shall integrate the class-level GOF patterns
double U; // Current under change the values of those properties that we
with higher-level and larger patterns (as in
lying price wish to be different from their ‘default’ values.
Buschmann 1996, Duffy 2004 and Jackson 2001)
double b; // Cost of carry 3. We wish to create portfolios of options and
in order to design a flexible and maintainable
that portfolios can consist of other sub-portfo-
option calculator program.
string optType; // Option name lios. In other words, we wish to create hierar-
chies of nested objects to any depth. This facility
Motivating design Patterns (call, put)
will allow us unlimited flexibility in the kinds of
In this section we motivate what a design pattern
public: structured products that we can create.
is (in a software development context) and we
// Functions that calculate option 4. Each of the member functions in the public
shall give a short account of how design patterns
price and sensitivities interface of EuropeanOption must be implement-
are being used in financial engineering software
double Price() const; ed by a piece of code that we call an algorithm.
projects. We focus on software systems using an
double Delta() const; For example, we can calculate the price of an
object-oriented language such as C++, Java, C# or
double Gamma() const; option by an exact formula (if we are lucky or
VB.NET because much of the design pattern liter-
double Vega() const; clever), by using the binomial method or by using
ature has been devoted to such languages. The
double Theta() const; a finite difference scheme (see for example, Duffy
examples in the current article will be in C++.
double Rho() const; 2004a). Of course, we could use a hard-coded
Imagine the following example. Let us sup-
}; switch (in this case an enum type in C++) but what
pose that you have written a class in C++ contain-

50 Wilmott magazine
happens if we now wish to use the Finite Element 1995 are grouped into three major categories (in Some examples
Method (FEM) in order to calculate the price? The total there are 23 specific patterns): We cannot describe all 23 design patterns in this
answer is that we would have to change the source ● Creational Patterns: these patterns abstract the introductory article. However, we return to the
code, change the definition of the enum and instantiation process. In general, they help make five problems mentioned earlier and we discuss
recompile: an application independent of how its objects are which patterns resolve these problems.
created, composed and represented. In rough Furthermore, we give a code example in C++ to
enum AlgorithmType {Exact, terms, creational patterns allow us to create “vir- show how one particular pattern is implemented.
Binomial, FDM, FEM}; tual constructor” mechanisms. Problem 1 is implemented by a Factory
● Structural Patterns: these are patterns that Method pattern that defines an interface (usually
This is not our idea of flexible software. The allow the developer to compose classes and in the form of pure virtual member functions)
problem is that the client code (in this case the objects to form larger structures. that you can override to suit your own needs.
EuropeanOption class) knows about each of the
above algorithms and must change when a new
one comes along. It is obvious that no amount of heroics on
5. Finally, what do we do if we wish to output
option price (and possibly its delta and gamma) the part of the software developer will help
to a spreadsheet program such as Excel? A possi-
ble answer would be to write three member func-
tions in EuropeanOption that write output to
resolve these problems unless he or she
Excel. That is indeed possible. The only problem
is that some clients do not need or want Excel
uses some clever design techniques
while others might wish to output to OpenGL,
Oracle, Access, GDI+ … Writing a member func- ● Behavioral Patterns: these are patterns that are There will then be a derived factory class for each
tion for each output choice leads to a class with concerned with algorithms and the assignment specific input option, for example a dialog box.
very many member functions and within no time of responsibilities between objects. In general, Problem 2 is resolved by application of the
becomes completely unmanageable. these patterns describe inter-object communica- Prototype pattern. In other words, you clone your
It is obvious that no amount of heroics on the tion and control flow in systems. own objects from a prototypical object. For exam-
part of the software developer will help resolve ● Each pattern has a name by which we can iden- ple, we have prototypical objects for different
these problems unless he or she uses some clever tify it and each one is documented in Gamma kinds of options.
design techniques. Fortunately, problems 1 to 5 1995 so that it can be applied to your own specif- Problem 3 is resolved by application of the
above have been encountered umpteen times in ic application. Each pattern is thus documented Composite pattern. This pattern is so important
software development projects during the last using the template: that we claim that it is always needed. By using
twenty years and so much experience has been ● The name and intent of the pattern this pattern developers can create complex
built for resolving these problems (in many con- ● A motivational example to show how it works objects such as portfolios, Collateral Debt
texts) that a number of authors have taken the ● A discussion of the applicability of the pattern Obligations (CDO) and other structured prod-
effort to document these design nuggets in hand- in general ucts. For example, using Composite we can create
book (or cookbook) form. Enter Design Patterns ● The classes that are needed in order to imple- a CDO object that contains other CDO objects
(Gamma 1995)! In short, a Design Pattern is a ment the pattern (the so-called structural view) which in their turn contain CDO objects.
description of a problem and its solution. The The interactions between the objects in order to Problem 4 is resolved by the Strategy pattern.
steps in solving the problem are always the same realise the pattern intent (the so-called behav- This pattern is very important in financial engi-
even though the context is different. ioural view) neering for obvious reasons: we need flexible
● The consequences of using the pattern algorithms for pricing options and other instru-
Design Patterns Classifications ● Tips and guidelines on applying the pattern ments. For example, we can define Strategies for
Design Patterns document proven experience in in C++ stochastic interest-rate models (for example Hull-
software development. Our interest is in apply- In short, this pattern documentation gives White) and branching algorithms (CRR, JR) in the
ing them to financial engineering applications the developer a kind of recipe that he or she can binomial method, to mention just a few.
in C++. In particular, we wish to create classes use and apply to financial engineering applica- Problem 5 is resolved by the Visitor pattern.
and objects in C++ that are easy to maintain and tions. This is a wonderful pattern because it allows us to
^
to extend. To this end, the patterns in Gamma extend the functionality of a class without hav-

Wilmott magazine 51
 DANIEL DUFFY

<?xml version="1.0"?>
Visitor object is a kind of driver that <EuropeanOption>
encapsulates new functionality for an <StrikePrice>100</StrikePrice>
<InterestRate>0.06</InterestRate>

object but is uncoupled from that object <Expiry>1</Expiry>

<Stock>120</Stock>
<UnderlyingAsset>134.2</Underlying
ing to add member functions to that class. This xmlW.visit(option); sset>
sounds like magic but it is quite easy to apply <CostOfCarry>12</CostOfCarry>
once you understand the basic structure. A xmlW.Save ("Option.xml"); </EuropeanOption>
Visitor object is a kind of driver that encapsulates
new functionality for an object but is uncoupled Summary
from that object. We take an example (taken from // Now read the file back in We have given an introduction to Design Patterns
Duffy 2004a) to show what we mean. The basic XMLReader<string, double> xmlR; and how they can be used to create flexible and
problem is that we wish to export an option’s xmlR.Load("Option.xml"); maintainable C++ classes for financial engineer-
properties and its values to an XML file. Instead of ing applications. The next two articles will dis-
writing a member function in the option class we cuss how to achieve the same effects using sys-
create an XML visitor object that does the same Entity<string, double> option2; tem-level patterns for medium-sized applications
job for us. The basic C++ code is: xmlR.visit(option2); and with Domain Architectures for large sys-
tems.
int main() return 0; Daniel J. Duffy
{ } © Datasim Education BV 2004
The Author
XMLWriter<string, double> xmlW; In this program we create an option object Daniel J. Duffy works for Datasim, Amsterdam in the
and two Visitor objects; one visitor writes the Netherlands (www.datasim.nl, www.datasim-compo-
Property<string, double> data to an XML file while the other visitor reads nent.com). If you have any comments please contact him
K("StrikePrice", 100.0); the data back in and regenerates the option at [email protected]
Property<string, double> object. This program use the Property Pattern as
r("InterestRate", 0.06); discussed in Duffy2003a.
Property<string, double> The output from this program is a standard
T("Expiry", 1); XML file whose contents are:
Property<string, double>
S("Stock", 120);
Property<string, double> REFERENCES
U("UnderlyingAsset", 134.2);
Buschmann, F. et al 1996 Pattern-Oriented Software John Wiley and Sons, Chichester, UK
Property<string, double> Architecture: A System of Patterns, John Wiley and Sons, Fowler, M. and Scott, K. UML Distilled, Addison-Wesley,
b("CostOfCarry", 12.0); Chichester, UK Reading, MA
Duffy, Daniel J. 2003 Financial Instrument Pricing using C++, Gamma, E. et al 1995 Design Patterns Elements of Reusable
Part I Using C++ for European Option Pricing and Sensitivities, Object-Oriented Software, Addison-Wesley, Reading, MA
Entity<string, double> Wilmott Magazine September 2003 Jackson, Michael 2001 Problem Frames, Addison-Wesley,
option("EuropeanOption"); Duffy, Daniel J. 2003a Financial Instrument Pricing using C++, Reading, MA
option.AddProperty(K); Part II Using C++ Templates to model Options and other Joshi, M. 2004 C++ Design Patterns and Derivatives Pricing,
option.AddProperty(r); Instruments, Wilmott Magazine November 2003 Cambridge University Press
Duffy, Daniel J. 2004 Domain Architectures: Models and Parnas, D. 1972 On the Criteria To Be Used in Decomposing
option.AddProperty(T);
Architectures for UML Applications, John Wiley and Sons, Systems into Modules, Communications of the ACM December
option.AddProperty(S);
Chichester, UK 1972, Volume 15, Number 12.
option.AddProperty(U);
Duffy, Daniel J. 2004a Financial Instrument Pricing in C++,
option.AddProperty(b); W

52 Wilmott magazine