Quant Developer

일반성의 손실, FloatingRateCoupon 클래서에서 언급한,은 물론 불행한 것이다. 그러나 클래스 인터페이스에서 일반성과 유용성의 균형이 필요할 경우에 생긴다; 클래스가 더 일반화되면 그것이 갖는 inspectors가 더 적어지고 리턴하는 정보도 적어진다. 상속의 레벨에서 더 많이 추가함으로서 문제는 해결된다. 그러나 이것은 복잡도를 증가시키고 자체적인 문제를 가져온다. FloatingRateCoupon의 현재 구현은 베스트 협상은 아닐지도 모른다; 하지만 당분간 우리가 살아갈수 있는 것이다.

Event::hasOccurred 함수의 구현은 간단하다: date comparison.
그러나 cash-flow date와 evaluation date가 같은때 무엇을 리턴해야만 하는지, 다시 말하면 instrument의 현재 가치에서 오늘의 payments를 포함해야만 하는지를 고민해야 한다.
이것은 주어진 desk에서의 conventions에 따르는 경향이 있다. 
QuantLib은 사용자가 global settings에 의해 이것을 선택하도록 만든다; 적당한 boolean flag를 hasOccurred로 보내는 것에 의해 아무때나 overridden될 수 있다. 

"CASH IS KING," says a sign in the office of StatPro's CFO. Cash를 다루기 위해 QuantLib는 pricing뿐만 아니라 bonds와 interest-rate swaps와 같은 coupon-bearing instrument를 분석하는 것을 제공해야만 한다. 이번 챕터는 cash flows와 coupons을 모델링하는 클래스는 다룬다.

4.1 The CashFlow class
 최상위 클래스는 CashFlow이며, 모든 cash flows를 위한 기본 인터페이스를 제공한다. 함수들은 cash flow의 date와 amount를 리턴한다. dates를 명시적으로 비교하는 것으로부터 어떤 것을 save하기 위해, 어떤 편리한 함수는 cash-flow 클래스들이 주어진 date에 이미 일어났는지 아닌지를 말해준다. 마지막으로 hook가 제공되므로 cash-flow 클래스들은 Acyclic Visitor pattern을 취할 수 있다; section 4.3에서 예제를 다룬다.
 라이브러리 예전 버젼에서, 이러한 모든 함수는 CashFlow class에 선언되었었다. date와 관련된 함수들은 CashFlow로부터 상속되는 Event class로 따로 떨어져 나왔다. 이 두개의 인터페이스는 listing 4.1에서 보여진다.
라이브러리는 SimpleCashFlow class의 간단한 구현을 제공한다. 이것은 date와 ammount to be paid를 취하고 date와 amount 함수들로부터 각각의 결과를 리턴한다.

//Listing 4.1: Interfaces of the Event and CashFlow classes.

4.2 Interest-rate coupons
 
//Listing 4.2: Interface of the Coupon class.

Coupon class는 주어진 day-count convention을 기반으로 하거나 주어진 기간동안에 interest rate를 accruing하는 것을 기반으로 하는 cash-flow를 위한 parent class로써 사용될 수 있다. 이것은 추상 클래스이다; cash flow를 위한 추가적인 인터페이스를 정의하고 date calculation를 다루는 몇몇 함수를 구현한다.
추상 인터페이스는 coupon에 의해 accrued된 interest rate를 리턴하는 rate 함수를 포함한다; dayCounter와 accruedAmount 함수는 accrual에 사용되는 day-count convention과 주어진 date까지의 cash amount accrued를 각각 리턴한다.
purely abstract인 rate 함수를 선언하기 위한 선택은 명백하다. 하지만 다른 두 함수는 다르다. dayCounter는 Coupon 클래스의 데이터 멤버로서 day counter를 저장해야한다(section 3.1에서 TermStructure 클래스를 예로 언급함) 더욱이 nominal 함수(개념적으로 비슷한)는 abstract가 아니지만 같은 데이터 멤버를 기반으로 한다. As I'm all for abstract interfaces, I don't complain - 그러나 asymmetry는 불편한 점이 있다는 것을 인정한다.
 accruedAmount 함수는 또 다르다; 이것은 wrong reason으로 abstract이다. 주어진 date까지의 accrual time과 notional에 곱의 결과를 갖는 rate 함수에 의해 default 구현을 갖을수도 있다. 이것을 abstract로 만드는 것은 amount 함수에 의해 rate 함수를 정의하는 파생 클래스들이 있기 때문에 앞서 말한 선택을 한것과 같은 것이다. 이러한 클래스들에서 accruedAmount는 더 효율적일 수도 있는 불확실한 grounds상에서 amount에 의해 정의된다. 그러나 올바른 선택은 default 구현을 Coupon 클래스에 추가하고 필요한 경우 override하는 것일 것이다. 이것은 다음 release에서 적용할 것이다.(amount 함수도 마찬가지이다)
 인터페이스의 나머지는 concrete 함수들로 이루어 진다. 생성자는 data 집합을 취하고 데이터 멤버에 저장한다; 데이터는 nominal of the coupon, payment date, accrual time을 계산하는데 필요한 dates를 포함한다. 보통 이러한 dates는 accrual period의 시작과 끝이다. 선택한 day-count convention에 의해 두개의 dates(reference period의 시작과 끝)가 더 필요할 지도 모른다; section A.2에 자세히 나온다.
저장된 데이터를 위해 Coupon class는 inspector를 정의한다; 특히 payment date를 리턴하는 것은 CashFlow 인터페이스에 의해 필요한 date 함수를 구현한다. 더욱이 accrualPeriod와 accrualDays함수가 제공된다; listing에서 보여지듯이 이것들은 주어진 day-count convention과 dates를 사용한다.
두개의 notes가 있다.
첫번째로, dayCounter 함수에 관한 것으로, 관련 dates를 저장하는 것과 대응되는 함수를 abstract로서 선언하는 것의 대체안을 가지고 있다. 전에 I'm all for abstract interfaces라고 말한것과 같다; 이 경우 거의 모든 파생 클래스에게 dates를 데이터 멤버에 저장하도록 하는 것과 같은 inspectors를 구현하게 하는것을 강요하는 것은 좋은 생각이 아닌 것 같다.(coupon dates를 데이터 멤버에 저장할 필요가 없는 파생 클래스만이 기존의 coupon을 decorating할 수 있을 것이다.) 만약 당신이 좋아한다면, dayCounter를 concrete 함수로 만드는 것도 가능하다.
두번째로, 정보는 레포팅과 같은 목적을 위해서 필요하기 때문에, inspectors에 dates를 노출하는 것은 명백히 맞는 것이다. 그러나 이것은 누군가가 accrualPeriod롸 같은 더 상위의 함수에 의존하는 것 대신에 그것들을 계산하는데 사용할지도 모른다. 물론 접근을 제한하는 것이 불가능하기 때문에 우리가 할수 있는 것은 이 이슈를 문서화하는 것이다.
 앞으로 accept 함수를 설명할 것이다.

4.2.1 Fixed-rate coupons
Coupon 인터페이스를 구현하는 concrete 클래스를 보자. 가장 간단한 것은 fixed-rate coupon을 모델링하는 것이다; FixedRateCoupon으로 불리고 구현은 listing 4.3과 같다.

// Listing 4.3: Sketch of the FixedRateCoupon class.

 실제로 현재의 구현은 매우 간단하지는 않다(비록 간단한 compounding coupon으로 시작하지만).
나중에 다른 compounding rules를 지원하도록 일반화되었다.
 생성자는 Coupon 생성자와 지불될 rate 그리고 accrual에 사용될 day-count convention을 인자로 취한다. listing에 있는 생성자는 simple rate를 취한다; 다른 생성자는 InterestRate 인스턴스를 취하기도 하지만 여기서는 생략하였다. nominal과 dates는 Coupon 생성자로 보내진다. 다른 인자는 데이터 멤버에 저장된다; 특히 rate(부동소수점으로 전달되는)는 InterestRate를 instantiate하는데 사용된다. 
 Coupon 인터페이스의 일부분(rate와 dayCounter 함수)은 저장된 값을 리턴하는 것으로 구현된다. 나머지 함수들(amount, accruedAmount)는 이용가능한 정보에 의해 구현된다. amount는 nominal과 coupon life동안에 compounded되는 rate를 곱하고 오직 accrued interest를 구하기 위해 nominal을 빼는 것에 의해 구할 수 있다. accrued amount는 비슷한 방식을 사용하지만 다른 accrual period를 사용한다.
 base Coupon 클래스에서 amount 함수를 위한 default 구현을 포함할 수 있다는 것을 언급했었다; 이것은 nominal을 rate와 accrual time을 곱하면 된다.

[이것은 이미 이 경우에 구현이 된것같다 - 그러나 이것의 유용함에 대해서는 합리적인 의심을 할수 있을 것이다. 소프트웨어 디자인은 절대 쉽지 않나?]

4.2.2 Floating-rate coupons
 FloatingRateCoupon 클래스는 대부분 소프트웨어의 상징적인 life이다. 이것은 간단하게 시작했고 더욱 복잡해 졌으며 현재 refactoring을 필요로 할지 모른다; 현재 구현은(listing 4.4) 여러개의 이슈를 포함하고 있다.(backward compatibility를 break하지 않고 수정을 한다면, release 2.0으로 가기 전까지 문제점을 가지고 갈것이다.)
 첫번째 이슈는 이름 자체이다: FloatingRateCoupon은 coupon의 특정 타입을 의미한다, 즉 LIBOR rate와 같은 종류로 지불하는 것을 말한다. 그러나 이 클래스는 더욱 일반적이며 다른 종류의 rates(CMS-constant maturity swap과 같은것들)를 지불하는 coupons를 모델링할수 있다. 불행히도 다른 이름은 더욱 안좋다; 예를들면, 이 단락을 쓰는 동안 간단히 고려하는 것(VariableRateCoupon)은 rate의 정의는 이 경우가 아닌 value를 바꿀지도 모른다. 대체로 지금 이름을 바꾸는 것은 어떤 의미도 없다고 생각한다.

// Listing 4.4: Sketch of the FloatingRateCoupon class.

 나의 투덜댐은 그만하고 구현을 보자. 생성자는 Coupon 클래스, day counter 그리고 interest-rate fixing과 관련된 여러 인자들에 의해 필요한 dates와 notional을 취한다. 이런 것들은 rate 계산(appendix A)과 fixing의 다른 details를 고려하면서 InterestRateIndex 클래스의 인스턴스를 포함한다; 말하자면 많은 fixing days, 체납금(arrears)에서 rate가 fixed되었든 아니든,와 optional gearing and spread. Coupon 생성자로 전달이 되지 않는 인자는 데이터 멤버에 저장된다; 인스턴스는 interest-rate index와 현재의 evaluation date의 observer를 등록한다. fixingDays와 inArrears 인자는 fixing date를 결정하는데 사용된다. gearing과 spread는 coupon이 rate(R = g * F + s)에 지불하도록 한다(g:gearing, F:fixing of the underlying index, s:spread).(이론적으로 negative gearing을 전달함으로서 reverse-floater coupons을 모델링할수 있지만, 실무에서 zero에서 implicit floor를 방치(neglect)하기 때문에 권할만하지 않다)
 그러므로 생성자 signature의 선택은 이 클래스에 의해 모델링될 수 있는 coupon의 종류를 제한한다. single index의 fixing을 기반으로 하는 rate로 제한한다; 두개의 rates사이의 spread를 지불하는 것들은 제외한다. spread 클래스를 생성하는 것과 InterestRateIndex로부터 그것을 상속하는 것에 의해 FloatingRateCoupon 클래스를 세밀히 조사하도록 강요당할수 있다(bolted); 그러나 이것은 모델링되는 financial concepts를 맴핑하는 것과 클래스 계층을 break할지도 모른다. 왜냐하면 두개의 indexes사이의 spread는 그 자체로 index가 아니기 때문이다. 아니면 최소 이것은 보통 고려대상이 아니다.
 다른 함수들은 CashFlow와 Coupon 인터페이스를 구현한다. floating-rate coupons가 fixed-rate보다 더 복잡하지만, amount 함수는 더 간단한 구현을 가지고 있다: 이것은 rate를 accrual time과 nominal에 의해 곱한다. 이것은 이것을 Coupon 클래스로 이동시키는 것을 지원하는 것처럼 보인다. accrualAmount 함수는 listing에는 없지만 다른 accrual time을 가진 비슷한 구현을 갖는다. 당분간, rate 함수는 skip할 것이다; 잠시후 구현에 대해 볼 것이다.
 inspectors를 보자. Coupon 인터페이스에서 필요한 dayCounter를 제외하더라도 우리는 index, fixingDays, gearing 그리고 spread와 관련된 파라미터를 리턴하는 것들을 가지고 있다. 마지막으로 함수들은 비지니스 로직을 구현하는 것들을 정의한다.
 첫번째 두개의 함수는 fixingDate와 indexFixing이다. 이것들은 충분히 직관적이다. fixingDate 함수는 체납에 coupon fixes가 있는지 아닌지를 확인하고, reference date를 선택하고(체납일 경우 coupon의 마지막 일자, 그렇지 않다면 시작일자), 필요한 fixing days로 backward한다; 휴일은 index calendar에 의해 skip한다. indexFixing 함수는 관련 일자에 fixing를 위해 저장된 index를 ask한다.
 두 함수의 signature와 관련된 이슈가 있다. 생성자는 single index를 가정한것 처럼 두개의 함수는 single index fixing을 가정한다. 이것은 일반화의 상실을 낳는다; 예를들어, 여러 fixing dates의 집합에서 index의 average fixing을 지불하거나 coupon like의 sub-period 상에서 rates를 compound하는 coupons은 제외된다.
 마지막 함수는 index fixing에서 가능한 convexity adjustment를 다룬다. adjustedFixing 함수는 rate 함수에 의해 쓰여지고 R = g · ˆF + s 공식을 adjusted fixing ˆF = (R − s)/g를 리턴하기 위해 도치시킨다. 이것의 구현은 취약한 점을 가지고 있다. 왜냐하면 rate와 fixing사이의 previous relationship에 의존하기 때문이다. 만약 파생 클래스가 이것을 수정한다면(예를들어 paid rate에 cap 혹은 floor를 더하는 것에 의해 - 이미 추가했다), 이 함수는 그에 맞게 수정되어져야만 한다.불행히, 이것은 프로그래머에게 남겨진다; 동시에 두개의 함수를 override하도록 강요하는 language feature는 없다.
 convexityAdjestment 함수는 original fixing과 adjusted one의 차이를 취함으로서 adjustment alone을 리턴한다. 이것은 protected convexityAdjestmentImpl 함수에 위임함으로써 수행된다; 이것은 이전 구현의 나머지 부분이고 각각의 분리된 함수의 존재는 계산을 최적화할수 있도록 한다. 이것은 더이상 현재의 구현에 필요하지 않다; protected 함수는 public으로 inlined되었다.
 이제 rate 함수를 보자. 라이브러리 이전버젼에서 다음과 같이 저장된 InterestRateIndex 인스턴스에 의해 제공되는 fixing을 기반으로 구현되었다.(현재의 convexityAdjustment 구현은 무한루프에 빠지게 만들지도 모른다.)


 새로운 요구사항이 필요함에 따라 구현은 변경되어야만 했다: floating-rate coupon은 여러가지 방법으로 pricing될수 있다. 이것은 Instrument 클래스에서 보았던 이슈이다.
 Instrument에서 했듯이, Strategy pattern을 사용했다. 그러나 여기서는 pattern의 구현이 다르다. context가 more specific하다; 우리가 원하는 결과를 알고 있었다. FloatingRateCoupon은 Instrument보다 더 많은 인터페이스를 갖는다. 이것은 불투명한 인자와 PricingEngine 클래스에서 사용되는 result strucutre를 피할수 있도록 만든다.
 FloatingRateCouponPricer class는 listing 4.5에 있다.

// Listing 4.5: Sketch of the FloatingRateCouponPricer class.

rates를 리턴하는 함수를 선언하고 있다: swapletRate는 coupon rate, adjusted for convexity, gearing and spread를 리턴하고, capletRate는 index fixing상의 cap에 의해 지불되는 adjusted rate를 리턴하고, floorletRate는 floor와 같은 것을 리턴한다. initialize 함수는 pricer가 인자 리스트에 일부분으로써 다른 함수에 전달되지 않는 정보를 제공하는 전달된 coupon의 reference를 저장하도록 한다.
 FloatingRateCoupon 클래스는 pricer 인스턴스를 취하고 그것을 coupon에 저장하는 setPricer함수를 정의한다(구현이 심플하지는 않다). 마지막으로 rate 함수는 listing 4.4에 있다: 저장된 pricer는 현재의 쿠폰으로 초기화되고 계산된 rate는 리턴된다.
 초기화가 rate함수가 아니라 setPricer 함수에서 수행되는 것을 보았을 것이다. 이것은 같은 pricer 인스턴스가 여러 개의 쿠폰에서 사용될수 있기 때문이다. 그러므로 pricer가 결과를 ask할 때마다 현재의 coupon이 저장되어 있는지를 확인해야만 한다. 이전의 계산은 다른 reference에 저장되어 있을지도 모른다 - 기다리게 할지도 모른다(dangling).
 물론 이 구현은 전체적으로 만족스럽지 못하다(이것은 최근 몇년동안 더욱 중요해 지고 있는 병행처리를 숨기고 있다. 현재 우리는 같은 pricer를 여러개의 coupon에 넘기지 못하고 그러므로 동시에 그것들을 평가하지 못한다). pricer 함수를 정의하는데 더 나은 디자인이 있을 것이다. 예를들면 다음과 같으며 반복되는 initialize 호출을 피할수 있다.

Rate swapletRate ( const FloatingRateCoupon& coupon ) ;

나는 이른 최적화의 guilty를 인정해야만 한다. 우리는 swapletRate와 다른 비슷한 함수들이 (floored coupon을 price하기 위해) 순서대로(in sequence) 호출될때, 각각의 초기화 함수들은 다른 rate 계산들에서 사용되는 accessory quantities를 미리 계산할 수 있다; we let that possibility drive the design. 결과적으로 대부분의 pricers는 initialize 함수에서 computation을 수행한다; 그러나 내 생각에 rate를 계산하기 위한 Texas two-step을 정당화하기에는 충분하지 않다.
 pricer machinery에 의해 추가되는 복잡함을 신경쓰지 않으면서 특정 floating-rate coupon을 구현하기를 원한다면, FloatingRateCoupon으로부터 상속을 하고, 계산을 직접수행하기 위해 rate 함수를 override하고 pricers에 대해서는 잊어라. 이것은 나중에 필요하면 추가할수 있다.

4.2.3 Example: LIBOR coupons
floating-rate coupon의 가장 공통된 것은 LIBOR index에 의해 fixed된 rate를 지불한다는 것이다. 이러한 coupon의 최소 구현은 listing 4.6에 있다. 

// Listing 4.6: Minimal implementation of the IborCoupon class.

 오직 필요한 멤버는 생성자이다. 이것은 FloatingRateCoupon과 같은 인자를 취하지만 전달된 index의 type을 특화한다; 이것은 이 인자가 더욱 일반적인 InterestRateIndex보다는 IborIndex 클래스의 인스턴스의 포인터가 되도록 제한한다.(Ibor 이름은 EURIBOR, LIBOR과 같은 index의 공통 suffix이다). 모든 인자는 부모 클래스의 생성자로 보내진다; index는 특별한 처리가 필요하지 않다. 왜냐하면 파생 클래스로의 shared 포인터가 그것의 베이스 클래스의 포인터로 묵시적으로 upcast될수 있기 때문이다.
 물론 실제 pricing work는 pricers에 의해 수행될 것이다. Listing 4.7은 그것들 중에 하나, BlackIborCouponPricer 클래스,의 구현의 일부를 보여준다; 이름 중에 Black의 의미는 adjustment를 계산하고 index fixing의 caps or floors를 위해 Black 모델을 사용한다는 것이다.

// Listing 4.7: Partial implementation of the BlackIborCouponPricer class.

 생성자는 LIBOR rate의 변동성을 기술하고 그것을 저장하며 observer로서 그것을 등록하는 term structure의 handle을 취한다. 만약 그 coupon rate가 연체되지않고 cap과 floor가 정의되지 않는다면, 변동성은 사용되지 않는다; 이러한 경우 handle은 비어있거나 생성자 호출시 생략될 수 있다.
 initialize 함수는 전달된 coupon이 IborCoupon으로 downcasting에 의해 올바른 타입을 갖는지 확인한다. 만약 맞다면 몇가지 사전 처리가 수행된다. 여기서 두개의 데이터 멤버에서 coupon gearing과 spread를 저장한다; 이것은 나머지 코드를 더욱 간결하게 작성할수 있도록 도와준다. swapletRate함수는 간단히 저장된 gearing과 spread를 adjusted rate로 적용하고 이것의 계산은 adjustedFixing 함수로 위임된다. 만약 coupon이 tenor(투자, 대출 등의 계약기간 중 현재 시점에서의 잔여기간을 말합니다.)의 시작에서 고정되면, adjusted rate는 underlying index의 fixing이다. 만약 coupon이 연체된다면, convexity adjustment가 계산되고 fixing에 추가될 것이다; 여기서 공식에 대한 구현을 보이지는 않을 것이지만 유효한 caplet volatility를 위한 check를 할 것이다. capletRate와 같은 다른 함수는 여기서 다루지 않을 것이다; 나중에 예제로 다룰 것이다.
 이것이 간단하지만 clean한 예제이다 - par coupons를 사용하여 floating-rate notes를 pricing하는 법. 라이브러리는 이러한 practice를 따르거나 그렇지 않도록 하게 할 수 있다; 이러한 방법은 몇가지가 있다.
 첫번째로 (listing 4.8) pricer machinery를 bypass하고 LIBOR coupon을 위한 rate 함수를 override하는 것이다. 만약 par coupons가 compilation flag를 셋팅하는 것에 의해 사용할 수 있고 coupon이 연체되지 않는다면(이 경우 여전히 pricer를 필요로 한다), built-in par-rate 계산이 사용된다; 다시 말하면 함수 호출이 base 클래스 함수로 보내진다면 계산은 pricer로 위임된다. 이것은 동작하지만 단점을 가지고 있다.

// Listing 4.8: Extension of the IborCoupon class to support par coupons.

 반면 pricer를 coupon에 설정하게 되면 observable 효과를 누릴수 없게 된다.
 어떤 다른 index fixing은 같은 날짜상에서 연체되지 않은 coupons fixing이나 연체가 된 것을 위해 사용될 수 있다. 이것은 parity relationships or worse, hedges를 버릴수(throw off) 있다.
 더 좋은 방법은 par-coupon pricer를 명시적으로 구현하는 것이다(Listing 4.9). 이것은 Black pricer를 상속함으로 인해 이루어진다. 

// Listing 4.9: Sketch of the ParCouponPricer class.

파생 pricer는 오직 adjustedFixing 함수를 override하면 된다; fixing을 위한 저장된 index를 asking하는 것 대신에 risk-free curve를 extract하고 그것을 par rate를 계산하는데 사용한다. 이것은 coupon 클래스에서 rate를 override하는 것보다 cleaner하고 같은 단점을 겪지 않게 되며 런타임시 선택할 수 있다.
 이 방법은 여전히 한가지 문제을 갖지만; convexityAdjustment 함수는 par fixing과 index fixing(convexity 효과때문이 아닌) 사이의 difference를 리턴할 것이다(coupon's rate 함수를 override할 때 같은 문제에 직면하게 된다). 불행히, 이것을 어떻게 고칠지는 분명하지 않다 - 최소한 나에게- 비록 몇개의 가능성은 있지만. 하나는 par coupons를 detect하고 null adjustment를 리턴하기 위해 convexityAdjustment를 override하는 것이지만 이것은 연체 coupons에는 동작하지 않을 것이다. 다른 가능성은 함수 이름을 adjustment로 바꾸고 더욱 일반화 시키는 것이지만 이것은 정보를 잃게된다. Best는 convexity adjustment의 계산을 pricer에 위임하는 것이다; 이것은 fragility 이슈를 극복하는데도 도움이 된다.

4.2.4 Example: capped/floored coupons
Caps와 floors는 어떤 종류의 floating-rate coupon에도 적용할 수 있다. 이 프레임워크에서 이것은 FloatingRateCoupon으로부터 파생되는 클래스에 generic way로 특징을 추가하기를 원하는 것을 의미한다.
 이러한 요구사항은 Decorator pattern을 사용하기를 제안하게 된다. CappedFlorredCoupon 클래스의 인터페이스는 listing 4.10에 있고 구현은 4.11.에 있다.

// Listing 4.10: Interface of the CappedFlooredCoupon class.

클래스는 베이스 FloatingRateCoupon 클래스의 포인터를 저장하고 필요한 행동을 추가하며 다른 곳에 저장된 객체의 함수를 호출하면서 Decorator pattern의 표준(canonical)을 따른다. 그러나 다른 언어와는 다르게 C++은 Decorator pattern을 구현하는 다른 방법을 제공한다: 다음과 같이 templates와 상속을 이용한다.


class template은 필요한 행동을 추가하거나 각각의 베이스 클래스의 함수를 호출하는 여러 클래스들(CappedFloored<IborCoupon> 또는 CappedFloored<CmsCoupon>과 같은)을 instantiate하는데 사용된다. 이때 기존의 것을 template 구현으로 대체할만한 강한 근거를 찾지 못했다; 그러나 CappedFlooredCoupon을 설명하는 동안 class template가 다르다(better or worse)는 것에 대해 살펴볼 것이다.
 놀랍지 않게도, 생성자는 데이터 멤버에 FloatingRateCoupon 인스턴스를 decorate하고 저장하기 위해 취한다. 

// Listing 4.11: Implementation of the CappedFlooredCoupon class.

DefaultProbabilityTermStructure의 구현에 있어, 전에 언급했던 것과 비슷한 symmetry break가 있다는 것을 인지하였을 것이다. 이번의 경우, discount factors는 privileged role이 주어졌다는 것이다. 이 경우 hazard rates는 학대당하는 stepsister의 역할이 주어졌다; survival 혹은 default density를 위해 선언된 비슷한 함수들을 제외하고 hazardRateImpl은 존재하지 않는다. 과거에 구현된 버젼을 보면 symmetric이었다; 이러한 변화에 대한 이유를 설명할수 없다 - 이번것은 good idea라고 확신하지만.
효과는 HazardRateStructure adapter를 파생하는 클래스는 hazardRateImpl을 직접 호출할수 없기 때문에, hazard rates를 리턴하기 위해 some hoops를 고려해야만한다; 대신에 default 구현을 사용해야만 하며 ratio of default density와 survival probability를 리턴해야만 한다. 불행히도 현재 우리의 요정 대모조차도 기존의 코드를 break하는 위험 없이는 이것을 바꿀수 없다.

PiecewiseYieldCurve 선언을 보면서 당신은 이말을 할지도 모른다. "Wait a minute, wasn't friend considered harmful?" 답은 yes - friend 선언은 encapsulation을 깨고 클래스의 tight coupling을 강요한다.
그러나 대안을 살펴보자. Bootstrap 클래스는 curve data로의 write 접근이 필요하다. 이것을 friend로 선언하는데다가 이것에 세가지 접근 방법을 준다. 반면 우리는 데이터를 Bootstrap instance로 넘겨야 할지도 모른다; 그러나 이것은 두개의 클래스를 tightly coupled할지도 모른다(the curve internals는 bootstrap 코드를 바꾸지 않으면 바뀔수 없다). 반면 public interface를 통해 curve data를 노출해야될지도 모른다; 그러나 이것은 encapsulation을 더욱 위반하게 된다(우리는 write 접근이 필요하다는 것을 기억하라). 우리는 데이터를 각각의 클래스에서 encapsulate하거나 접근을 제어하기 위해 private 상속을 사용할지도 모른다. 릴리즈 1.0에서 우리는 friend 선언이 두개의 대안보다 더 좋다고 생각했다. 세번째(and best) 대안이 다음 릴리즈에서 구현될지도 모른다.

http://goo.gl/jMiUA

http://goo.gl/1NQD4

http://goo.gl/7uI1n

interpolated discount와 forward curves의 코드를 보면 interpolated zero-yield curve와 많이 비슷하다는 것을 알 수 있을 것이다. 자연스럽게 의문점이 생각날 것이다: 공통 코드를 추상화하는 것이 가능하지 않을까? 혹은 하나의 클래스 템플릿이 가능하지 않을까?
대답은 각각 yes 와 no이다. 어떤 코드는 template 클래스로 추상화 될수 있다. 그러나 curves는 반드시 세개의 abstract 함수를 구현해야만 한다(discountImpl, forwardImpl, zeroYieldImpl). 그래서 우리는 여전히 공통 코드와 세개의 모든 클래스가 필요하다.

당신은 George Orwell's Animal Farm에서 몇몇 term structures가 다른 것들 보다 더 equal하나도 주장할 지도 모른다. discount-based 구현은 base YieldTermStructure 클래스에서 사용되어지는 것으로 보아 특권이 있는 역할을 가지는 것처럼 보인다. 다욱 symmetric한 구현은 base 클래스(대응되는 pulic 함수들로부터 불리워지는 discountImpl, zeroYieldImpl, forwardImpl)에서 세개의 abstract 함수들을 정의하고 기존의 것에 DiscountStructure 클래스를 추가하면서 세개의 adapters를 제공할지도 모른다.
argument는 sound하다; 사실 YieldTermStructure 클래스의 최초 구현은 symmetric하다. discount-based interface로 교체하는 것과 그것의 이유는 mists of time에서 길을 잃었다(lost in the mists of time), 그러나 InterestRate instances의 사용과 함께 할일이 있을지 모른다; compounding와 frequency의 변화가 필요하기 때문에 zeroYield(to name one method)는 직접 zeroYieldImpl의 결과를 리턴하는 것을 허락하지 않을 것이다.

만약 평가된 date가 설정되지 않았다면 Settings 클래스는 기본으로 오늘의 date를 리턴한다. 불행히도 이것은 strike of midnight에 조용히(observers에게 알리지 않은채) 바꾼다. 이것은 미스터리한 에러를 발생시킨다. 만약 당신이 overnight calculations를 수행하고 있다면, 히어로즈의 히로상과 같은 위엄을 수행해야만 할것이다 - freeze time. evaluation(평가된) date를 오늘 date로 셋팅하는 것은 명백히 고정이 되는 것이다. 이것은 오늘이 내일로 넘어가도 마찬가지가 된다.

알고 있을만한 trick: 만약 너의 모든 term structure가 이동한다면, 평가된 date를 내일의 date(당연히 모든것들은 변하지 않도록 유지하면서)로 설정하고 당신의 instruments의 가치를 재평가하는 것은 당신에게 당신의 포트폴리오의 daily theta를 주게 될 것이다.  

변화는 오직 거듭된다. - 헤라클레이토스(Heraclitus). 역설적으로 이 격언은 25세기가 지난 이후에도 여전히 유효하다; Quantitative finance에서 모두는 아닐지라도 대부분의 quantities는 분명 시간이 지날수록 다르게 된다. 이것이 우리를 term structures의 주제로 이끈다. 이번 챕터에서 이것을 위한 기본과 사용되고 있는 몇개의 term structures에 대하여 다룰 것이다.

3.1 The TermStructure class
term structures를 위한 현재의 base 클래스는 사후의 디자인으로서 좋은 예제가 된다. 조금 생각해보면 이러한 클래스를 위한 명세를 생각해 낼 수 있을 것이다; 우리가 라이브러리를 시작했을 때 우리는 하지 못했었다. 몇 년 후 나이가 더 들고 조금 더 현명해져 우리는 존재하는 term structures를 보고 그것들의 공통 특성을 추상화냈다. 그 결과가 이 섹션에서 다루게 되는 TermStructure class이다.

3.1.1 Interface and requirements
추상화되고 나면, 다음의 리스트에 나타나는 base term-structure 클래스는 세개의 기본적인 tasks에 대한 책임이 있다. 첫번째는 자신의 reference date 즉 어떤면으로 보면 미래가 시작하는 date를 계속 따라가야 하는 것이다(이것은 모든 term structures에 반드시 적용되야 되는 것은 아니지만, 당분간 이대로 진행할 것이다.) volatility term structure인 경우, 대부분은 오늘인 경우가 많다. yield curve인 경우, 오늘일지도 모른다; 그러나 desk에서 사용되는 conventions에 따라(예를 들면, 두번째 비지니스 데이에 모든것을 정산하는 interest-rate swap desk의 거래같은 경우) reference date는 몇 settlement days에 의해 오늘보다 앞에 있을수도 있다. 우리의 term-structure 클래스는 필요하다면 반드시 이러한 계산을 수행할 수 있어야 한다. 또한 reference date가 외부에 명시되는 경우(sequence of dates, including the reference가 대응되는 discount factors로 표를 만드는 경우)가 있을 수 있다. 마지막으로 reference date의 계산은 다른 객체로 위임될 수 있다; 이것은 3.2.4에서 다룰 것이다.

모든 경우에 reference date는 referenceDate 함수에 의해 클라이언트 코드로 제공될 것이다. 이와 관련된 calendar와 settlementDays 함수는 calendar와 settlement day를 리턴한다.
두번째 task는 dates를 times으로 변환한다. 즉 reference date에서 t = 0로 시작하는 real-valued time axis상에 표시한다. 이러한 times는 discount factor를 zero-yield rates로 바꾸거나 curve와 관련된 수학적인 모델에서 사용될수 있다. timeFromRederence 함수에 의해 파생된 클래스들의 작성자는 계산을 이용할 수 있다.
세번째 task는 주어진 date와 time이 term structure에 해당하는 도메인에 속하는지 아닌지를 판단하는 것이다. TermStructure 클래스는 파생클래스에 도메인에서 latest date의 명세(maxDate 함수에서 반드시 구현되어야만 하는)를 위임하며 실제 테스트를 수행하는 overloaded checkRange 함수와 대응되는 maxTime 함수를 제공한다; 도메인은 reference date에 시작하는 것을 가정하므로 minDate 함수는 존재하지 않는다.

3.1.2 Implementation
첫번째 task는 term structure를 instantiated하면서 시작한다. 어떻게 reference date를 계산하는지에 따라 다른 생성자가 호출된다.(Section A.2에 date, time과 관련된 설명이 있다) 그러한 모든 생성자는 두 개의 boolean 데이터 멤버를 set한다. 첫번째는 moving_이라 불리며 오늘의 date가 변할때 reference date가 이동하면 true로 셋팅하고 date가 고정이면 false로 셋팅한다. 두번째 updated_는 다른 데이터 멤버 값(reference date의 최종 계산된 값이 저장되는 referenceDate_)이 현재 최신값이거나 아니면 재계산이 되어야하는지를 나타낸다. 세개의 생성자가 가능하다. 하나는 간단히 time 계산에 사용되는 day counter를 가지지만, reference-date 계산과 관련된 인자를 갖지는 않는다. 결과로 나오는 term structure는 date를 계산하기 위한 수단을 갖지 않는다; 그러므로 이 생성자를 호출하는 파생 클래스는 반드시 virtual referenceDate 함수를 overriding해서 계산을 해야만 한다. 구현은 base 클래스에서 더많은 계산을 하는 것을 억제하기 위해 updated_를 true로 moving_을 false로 설정한다.
다른 생성자는 date를 가지며 optional calendar 그리고 day counter를 갖는다. 이것이 사용되면 reference date는 주어진 date와 같으며 고정으로 간주된다. 게다가 referenceDate_를 전달된 date로 셋팅하고 moving_를 false, update_를 true로 설정한다.
마지막으로 세번째 생성자는 여러개의 settlement days와 하나의 calendar를 갖는다. 이게 사용되면, reference date는 주어진 calendar에 의한 business days에 의해 advanced된 today's date로 계산된다. 게다가 대응되는 데이터 멤버로 넘겨받은 데이터를 복사하면서, moving_를 true로 updated_를 false(이 시기에 계산이 수행되지 않으므로)로 설정한다. 그러나 이것이 전부가 아니다; 만약 오늘의 date가 변하면 term structure는 반드시 reference date를 갱신해야한다. Settings 클래스(Section A.6에서 설명됨)는 observer로써 등록된 term structure를 가지고 현재 측정한 date에 global access를 제공한다. 변화가 감지되면 update함수가 실행된다. 만약 reference date가 move하면 함수의 body는 term structure 자신의 observers에 알리기 전에 updated_를 false로 바꾼다.

calendar 함수와 같이 하찮은 것을 제외하고 첫번째 task의 구현은 referenceDate 함수와 함께 완성된다. 만약 reference date가 계산되야 하면, 이것을 리턴하기 전에 referenceDate_ 데이터 멤버에 결과를 저장하고 현재 측정된 date, advancing it as specified,를 가지고 계산한다. 이것은 새롭게 정의된 evaluation date로 term structure를 옮긴다.
두번째 task는 dates를 times으로의 변환이 전부 DayCounter instance로 위임할 수 있기 때문에 더욱 간단하다. 이러한 day counter는 보통 term structure를 생성자 인자로서 넘겨지고 dayCounter_ 데이터 멤버로 저장된다. 이러한 변환은 reference date와 넘겨진 date사이의 years를 위한 day counter를 ask하는 timeFromReference 함수에 의해 다루어진다. 함수의 body에서 day counter와 reference date는 데이터 멤버가 아니라 대응되는 함수에 의해 접근된다. 이것은 referenceDate 함수가 전부 overridden될 수 있어서 데이터 멤버를 무시할수 있기 때문에 필수적이다; 이와 같은 것은 dayCounter 함수에도 마찬가지로 적용된다.
당신은 이것이 code smell(Kent Beck이 만든 용어)이라는것에 반대할지도 모른다. term-structure instance는 함수에 의해 사용되는 실제의 것과 대응되지 않는 day counter 또는 reference date(or likely both)를 저장할지도 모른다. 이것이 헷갈리게 만든다; 사실 이전버젼의 클래스는 완전히 virtual인 dayCounter 함수를 선언했었으며 데이터 멤버를 포함하지 않았었다. 그러나 reference date의 경우 계산된 값을 저장할 데이터 멤버를 필요로 하기 때문에 이것은 필요악이다. broken-window effect로 인해 day count, calendar 그리고 settlement days는 뒤를 따랐다(모두 같은 데이터 멤버들을 정의해야만 했던 많은 파생된 term structures를 개발한 기간 이후에)
마지막 질문이 남았다: what day counter should be used? 다행히도, 이것은 크게 상관이 없다. 만약 누군가 오직 dates(term structure의 생성자에 date를 input으로 전달하고 값을 찾기위해 인자로서 dates를 사용한다면)와 작업한다면, day counter가 충분히 잘 동작하는 한 특정 day counter를 선택하는 노력은 아무런 대가를 얻지 못할 것이다: 예를들면, 만약 이것이 동질의 것이고(만약 두짝의 dates가 same number of dates를 갖지만 다르다면 즉 두 개의 dates d1, d2 사이에 time T(d1, d2)이 d3, d4 사이의 time T(d3, d4)가 같다), additive한것(T(d1, d2) + T(d2, d3) = T(d1, d3)). 두 개의 day counters는 actual/360과 actual/365-fixed이다. 비슷하게 만약 어떤것이 오직 times와 관련해 동작한다면 day counter는 전혀 사용되지 않을 것이다.
세번째 그리고 마지막 작업이다. 유효한 date range를 정의하는 것은 파생 클래스에 위임한다. 파생클래스는 maxDate 함수(여기서 purely virtual로 선언된)를 정의해야만 한다. 대응되는 time range는 timeFromReference 함수에 의해 latest valid date로 변환하는 maxTime 함수를 사용하여 계산한다. 마지막으로 두개의 checkRange 함수는 실제 range checking (time으로 변환한 후에 다른 곳으로 request를 forward하는 것으로 date를 취하는 것)을 구현하고 만약 전달된 인자가 valid range에 없으면 예외를 발생시킨다. 이러한 확인은 term-structure의 도메인 밖에서 추정(외삽법)하기 위한 요청에 의해 overridden된다; 이것은 optional boolean 인자를 checkRange 함수로 전달하거나 TermStructure를 상속하는 Extrapolator 클래스(Section A.5)에서 제공하는 facilities를 사용하여 이루어 진다. 외삽법은 오직 maximum date에 의해 수행된다; reference date가 거부되기 전의 dates를 위한 요청.

3.2 Yield term structures
YieldTermStructure 클래스는 TermStructure보다 먼저 date가 온다(predates) - 사실 이것은 라이브러리에서 유일한 term structure일때 TermStructure back in the day라고 불리기도 한다. 하지만 우리는 아직 그런걸 본적은 없다(we still hadn't seen the world). 이것의 인터페이스는 curve 도메인에서 특정 date에 interest rates와 discount factors를 예측할 수 있는 수단을 제공한다; 또한 이것은 concrete yield curve를 작성하는 일을 더 쉽게 도와주는 장치를 구현한다.

3.2.1 Interface and implementation
YieldTermStructure 클래스의 인터페이스는 listing 3.3에 나타나 있다. 생성자는 인자를 TermStructure 클래스의 대응되는 생성자로 보낸다 - nothing to write home about. 다른 함수는 다른 방식으로 yield structure상의 정보를 리턴한다; zero rates, forward rates 그리고 discount factors를 리턴할 수 있다.(rates는 InterestRate 클래스의 인스턴스로 리턴된다-section A.4); 이것들은 overloaded되서 dates 혹은 times의 함수로서 정보를 리턴할 수 있다. 당연히 zero rates, forward rates 그리고 discount factors 사이에 관계가 있다; 이것들의 어떤 하나의 지식도 다른 것을 연역(deduce)하는데 충분하다(여기서는 다루지 않는다). 구현에 나타나 있고 listing 3.4에 있다; protected discountImpl abstract 함수에 의해 직/간접적으로 모든 public 함수들을 구현하는데 Template Method pattern을 사용한다. 파생된 클래스들은 오직 위의 quantities를 리턴하기 위해서만latter를 구현할 필요가 있다.

3.2.2 Discount, forward-rate, and zero-rate curves
만약 파생 클래스의 저자가 discountImpl을 구현하지 않기를 원한다면? 결국 누군가 zero rates에 의해 yield curve를 기술하기를 원할지도 모른다. Quantlib는 이러한 경우에 사용되는 몇개의 클래스를 제공한다. 두개의 클래스인 ZeroYieldStructure와 ForwardRateStructure이며 listing 3.5에 나타난다.

이것들은 YieldTermStructure의 zero-discount 기반의 인터페이스를 zero-yield와 instantaneous-forward rates의 인터페이스로 변환하기 위해 Adapter pattern을 사용한다.
ZeroYieldStructure의 구현은 간단하다. 여기에는 없는 몇 개의 생성자는 자신의 인자를 parent YieldTermStructure 클래스의 대응되는 생성자로 전달한다. Adapter pattern은 protected section에서 구현된다: abstract zeroYieldImpl 함수가 선언되고 discountImpl 함수가 구현되는데 사용된다. 그러므로 파생 클래스의 저자는 fully functional yield curve를 얻기 위해 zeroYieldImpl의 구현을 제공하기만 하면 된다(당연히 다른 필요한 함수(maxDate와 같은)는 반드시 구현되어야만 한다). discount factor를 구하기 위해 사용된 formula 때문에 이러한 함수들은 continuously-compounded annualized rates로서 zero-yields를 리턴해야만 한다.
비슷하게, ForwardRateStructure 클래스는 파생 클래스에서 forwardImpl 함수를 구현함으로써 instantaneous forward rates(on an annual basis)에 의해 curve를 기술할수 있는 수단을 제공한다. 그러나 이것은 added twist를 갖는다. 주어진 time T에서 discount를 얻기 위해 우리는 0와 T사이의 instantaneous forwards의 평균을 구해야 하고 그러므로 원하는 zero-yield rate를 구할수 있다. 이 클래스는 forwards의 shape상에서 어떠한 가정을 만들수 없다; 그러므로 할수 있는 모든 것은 numerical integration이다 - an expensive calculation. 최적화를 위한 hook를 제공하기 위해 평균은 더 빠른 계산이 가능할때 overridden을 할 수 있는 virtual zeroYieldImpl 함수에서 수행된다. 당신은 만약 zero yields를 위한 expression이 가능하다면 zeroYieldStructure를 상속하는 것을 반대할지도 모른다; 그러나 이것은 만약 모델에 실제 초점을 맞춘다면 forwards에 의해 curve를 표현하는 것이 개념적으로 더 쉽다.
두개의 adapter classes와 base YieldTermStructure 클래스로 interpolated discount, zero-yield 그리고 forward curves를 구현할 수 있다. Listing 3.6에서 InterpolatedZeroCurve 클래스 템플릿을 outline한다; 다른 두개(InterpolatedForwardCurve와 InterpolatedDiscountCurve)는 같은 방식으로 구현된다.

template argument Interpolator는 두배의 task를 갖는다. 반면 이것은 traits(특성) 클래스로써 행동한다[18]. 이것은 이것의 속성(points-linear interpolation을 위해서는 최소 두개)과 interpolation 그리고 선택한 interpolation이 global인지(data point를 moving하는 것이 point를 포함하지 않는 interval에서의 interpolation을 변화시키는지 아닌지; cubic splines와 같은 것이 있음)를 명시한다. 반면 poor man's factory로 double된다; data points의 set이 주어졌을 때, 대응되는 Interpolation instance를 build하고 return하는 것이 가능하다 - (Interpolation 클래스는 section A.5에 나온다. A.5는 몇개의 이용가능한 interpolations와 대응되는 traits에 대해 다룬다)
public 생성자는 curve를 build하는데 필요한 data를 취한다: interpolate하기 위한 dates의 set, 대응되는 zero yields, day counter 그리고 optional interpolator instance. 대부분의 interpolations에는마지막 parameter는 필요하지 않다; 이것은 필요할 때 보내질수 있다. 구현은 parent ZeroYieldStructure 클래스로 passed dates의 첫번째 것(curve를 위한 reference date로 가정)과 day counter를 보낸다; 다른 인자들은 대응되는 데이터 멤버에 저장된다. 몇개의 일관성 확인을 수행한 후, dates를 times(전달된 reference date와 day counter를 이용하여) 변환하고, Interpolation instance를 생성할 것을 interpolator로 문의하고 그 결과를 저장한다.
이때 curve는 사용준비가 된다. 필요한 다른 함수는 one-liners로 구현된다; maxDate 함수는 전달된 dates의 제일 마지막을 return하고 zeroYieldImpl은 zero yield의 interpolated value를 리턴한다. TermStructure machinery는 이미 range-checking을 했기 때문에, Interpolation instance를 호출하는 것은 true argument를 포함한다. 이것은 만약 전달된 time이 주어진 range를 벗어났다면 그 값을 extrapolated하도록 만든다.
마지막으로 InterpolatedZeroCurve 클래스는 몇개의 protected 생성자를 정의한다. 이것들은 parent ZeroYieldStructure 클래스와 optional Interpolator instance의 생성자와 같은 인자를 취한다. 생성자들은 parent-클래스 생성자에 대응되는 인자를 보내지만, interpolation을 생성하지는 않는다 - 이것들은 zero-yield 데이터를 가지고 있지 않기 때문에 할수가 없다. 이것들은 InterpolatedZeroCurve를 상속하는 것이 가능하다; 파생된 클래스들은 data를 제공하며 그들이 취한 인자가 무엇이든(다음 섹션에서 다룸) 그것을 기반으로 interpolation을 생성한다. 같은 이유로 대부분 데이터 멤버는 mutable로 선언된다; 이것은 파생클래스가 interpolation을 lazily하게 update할수 있도록 만든다.

3.2.3 Example: bootstrapping an interpolated yield curve
이번 섹션에서는 all-purpose yield-curve template를 build할 것이다. 지난 서브 섹션에서 기술한 클래스 build하면서 discount facotrs, zero-yields 혹은 instantaneous forward rates상에서 다양한 방법의 interpolate하기 위한 방법을 설명하였다. curve의 nodes는 quoted market rates로부터 bootstrapped될 것이다.
말할 필요없이 이번 예제는 꽤 복잡할 것이다. 설명할 class template(PieceWiseYieldCurve)은 몇개의 helper 클래스들과 template tricks를 사용할 것이다. 필요한 모든것을 설명하도록 노력할 것이다.
class template는 listing 3.7에 있다. 클래스는 세개의 template arguments를 취한다. 처음 두개는 underlying data와 interpolation 함수를 선택한다; 우리의 목표는 template를 다음과 같같거나 비슷한 것으로 instantiate하는 것이다: PiecewiseYieldCurve<Discount, LogLinear>
첫번째 parameter는 bootstrap traits이다; 두번째는 이미 기술한 interpolator이다. 세번째 parameter는 bootstrapping algorithm을 구현하는 클래스를 명시한다. parameter는 default value(InterativeBootstrap class)를 갖기 때문에 대부분 이것을 몰라도 된다; 다른 bootstrapping algorithm으로 바꾸어도 된다. 이것의 문법이 익숙치 않은 사람들을 위해 template template parameter를 기술할 것이다[22]. template 두번이 맞다; parameter는 typename보다는 uninstantiated class template(이 경우 하나의 template argument를 취한다)이어야만 한다.(uninstantiated template는 std::vector와 같은 것이어야 하고 std::vector<double>과 같은 instantiated one과 반대의 개념이다. 두번째는 type의 이름을 주었지만 두번째는 아니다)
class interface를 선언하기 전에, curve의 parent class를 결정하기 위한 template programming가 필요하다. 반면 우리는 LazyObject class로부터 term structure를 상속한다; chapter 2에서 기술한 것과 같이 이것은 curve가 re-bootstrap를 스스로 할수 있도록 만든다. 반면 section 3.2.2에서 기술한 interpolated curves중 하나로부터 그것을 상속하기를 원한다; underlying data(discount, zero yields, forward rates)의 선택에 따라 class templates를 선택해야만 하고 선택한 interpolator class를 가지고 instantiate해야한다. 이것은 class template를 bootstrap traits에 저장하는것으로 이루어진다. 불행히, C++은 template typedefs를 허용하지 않는다(Template aliases는 아마 C++ standard 다음 revision에 소개될것이다). 그러므로 traits는 template parameter로서 interpolator를 취하고 typedef로서 instantiated parent class를 정의하는 inner class template curve를 정의할 것이다; 이것은 Discount traits의 정의에서 볼수 있으며 listing 3.8에 부분적으로 나타나 있다.
기술된 machinery는 다음 표현에 의해 선택된 class를 알리며 우리는 이것을 parent classes의 list에 추가할수 있다(이 표현을 컴파일러가 읽을때 컴파일러는 Traits가 무엇인지 모르며 Traits::curve가 class template 라는 것을 결정 할 수 있는 수단을 가지고 있지 않다. keyword를 추가하는 것이 컴파일러에 표현의 나머지 부분을 제대로 처리하는데 필요로 하는 정보를 준다): Traits::template curve<Interpolator>::type


instantiation은 bootstrap traits로서 Discount와 interpolator로서 LogLinear가 예제로 있으며 Discount::curve<LogLinear>::type는 InterpolateDiscountCurve<LogLinear>와 대응된다.
curve를 구현하기 전에 long template 표현을 피하기 위해 몇개의 typedefs를 정의한다: base_curve, this_curve, helper. 첫번째는 parent class를 의미하고, 두번째는 우리가 정의한 방금 그 클래스를 의미하며; 세번째는 helper class의 type을 bootstrap traits로부터 추출한다. 이것은 instrument의 quoted value와 bootstrapped되는 term structure의 instrument를 평가하는 수단으로 제공된다. bootstrap은 두개의 값이 일치(coincide)할 때까지 curve를 수정할 것이다. 마지막으로 두개의 typedefs는 두개의 대응되는 template arguments를 저장하므로서 나중에 검색할 수 있게된다.
마지막으로 실제 인터페이스이다. listing에서 보여지는 유일한 생성자들은 parent interpolated curve를 instantiating하기 위해 필요한 인자들과 a vector of helpers 그리고 bootstrap를 위한 target accuracy를 취한다. 다음으로 많은 inspectors(such as times or data)가 정의되고 parent class의 versions을 overriding한다; 이렇게 하는 이유는 마지막에 설명한다. public interface는 update 함수에 의해 완성된다. 
performCalculations를 포함한 protected 함수들은 LazyObject interface를 구현하는데 필요하다; parent-class 버젼을 override하는 discountImpl(public inspectors와 같은). Bootstrap class template는 curve의 type과 함께 instantiated된다. 이것은 curve의 internals로 접근이 필요할 것이기 때문에 결과 클래스는 PiecewiseYieldCurve class의 friend로써 선언된다; BootstrapError class도 마찬가지다. 마지막으로 bootstrap class의 instance와 required curve accuracy 그리고 helper를 저장한다.
구현을 보자. 생성자는 놀랄일이 없다: base class에 필요한 인자를 넘기고 다른것들은 클래스에 저장한다. 마지막으로 저장된 Bootstrap instance에 curve를 전달하고 some preliminary work를 수행하도록 만든다. update 함수는 정확함(disambiguation)을 위해 필요하다; 함수의 구현을 정의하는 두개의 클래스(LazyObject와 TermStructure)로 부터 상속한다. 컴파일러는 당연하게 second-guess를 거부하므로서 우리는 명시적으로 두개의 parent 구현을 호출해야만 한다.
performCalculations는 작업을 Bootstrap instance에 위임한다. 마지막으로 discountImpl 함수를 보면 왜 이러한 함수가 overridden되어야만 하는지를 알수 있다; parent-class 구현을 호출하기 전에, data가 calculate 함수를 호출하는 것에 의해 bootstrapped되어야 한다는 것을 확실히 해야만 한다. 이것은 또한 같은 패턴을 따르면서 다른 overridden inspectors를 hold한다. 이시점에 BootstrapHelper class template를 기술해야 한다; 이것은 listing 3.9에 있다. curve를 위해 우리는 이것(이전의 Discount traits에서 볼수 있는)을 BootstrapHelper<YieldTermStructure>로서 instantiate한다; 편리를 위해 라이브러리는 더욱 verbose type name에서 사용할 수 있는 RateHelper로 불리는 클래스에 alias를 제공한다.

이 클래스의 각각의 instance - 혹은 파생된 클래스의; 클래스 자체가 abstract이다 - 는 curve상에 하나의 노드를 bootstrapping하는 것을 도울 것이다. node를 위한 input datum은 instrument의 quoted value이다; 값이 시간에 따라 변하기 때문에 Quote instance로의 Handle로서 제공된다. yield curve의 경우 이러한 instruments는 deposits 혹은 swaps이고 market rates로서 quoted된다. 각각의 instrument에는 파생된 클래스가 제공되야만 한다.
모든 helper에 공통인 functionality는 base class에서 구현된다. BootstrapHelper는 Observer와 Observable을 상속한다; 두개의 역할은 market value를 등록할수 있게 하며 새로운 bootstrap의 수행의 필요성을 signaling하면서 변화를 curve에 알릴수 있다. 이것의 생성자는 input market value를 제공하는 Handle<Quote>를 취하고 그것을 데이터 멤버에 저장하며 observer로서 자신을 등록한다. 세개의 함수는 underlying instrument value를 다룬다. quote 함수는 quoted value를 포함하는 handle를 반환한다; abstract impliedValue 함수는 bootstrapped되는 curve상에서 계산한 값을 리턴한다; convenience 함수인 quoteError는 두 값의 signed 차이를 리턴한다.
두개의 함수가 bootstrap algorithm을 set up하기 위해 더 사용된다. setTermStructure 함수는 만들어지는 curve와 함께 helper를 연결한다. latestDate 함수는 시장 데이터의 implied value를 계산하기 위해 사용되는 curve data를 위한 latest date를 리턴한다(latest required date는 instrument의 maturity와 일치할 필요성은 없다. 예를 들어 만약 instrument가 constant-maturity swap인 경우, curve는 마지막 coupon에 의해 지불되는 rate를 예측하기 위한 swap maturity보다 몇년을 확장해야 할 것이다.); 이러한 date는 bootstrapped되는 노드의 coordinate로서 사용될 것이다. 마지막 함수(update)는 quote로부터 helper의 observers로 notification을 전달한다.
라이브러리는 RateHelper를 상속하는 몇개의 concrete helper classes를 제공한다. 간략함을 위해 실제 코드를 보여주는 대신 hand-waving(간단한 말?)을 사용할 것이다. 각각의 helper 클래스는 특정 instrument를 위해 impliedValue를 구현하고 적절한 latest date를 리턴하기 위한 code를 포함한다. 예를들면, DepositRateHelper 클래스는 이것의 시작과 maturity date 사이의 forward rate를 위한 curve를 asking함으로서 quoted deposit rate를 예측한다; 반면 SwapRateHelper 클래스는 Swap 객체를 instrantiating하고 bootstarapped되는 curve상에서 pricing하고 fair rate를 implying함으로서 swap rate를 예측한다.
bootstrap code를 보자. Listing 3.10에서 라이브러리에서 제공되고 default로 사용되는IterativeBootstrap class의 인터페이스를 보자. 편의를 위해 curve로부터 traits와 interpolator types를 추출하기 위해 typedefs가 정의된다. 생성자와 setup 함수는 특정 흥미 대상이 아니다. 첫번째는 term-structure pointer를 null로 초기화한다; 두번째는 전달된 curve pointer를 저장하고 curve를 bootstrap하기 위해 충분한 helper를 가지고 있는지 확인해야하며 각각의 helper의 observer로서 curve를 등록한다. bootstrap algorithm은 calculate 함수에 의해 구현된다. 여기서는 details와 corner cases는 대충 넘어간다; 관심있다면 라이브러리 풀 코드를 보면 된다.
첫번째로 모든 helper는 현재의 term structure로 셋팅한다. 이것은 a set of helpers가 각각 다른 curves를 사용하도록 할 때마다 수행된다(멀티 쓰레드 환경이라면 안전하게 하기 위해 당연히 같은 helpers은 다른 curves에 넘겨질수 없다. QuantLib의 대부분은 thread-safe가 아니다.) 그리고 vectors가 초기화된다. 초기 노드를 위한 date와 value는 전달된 traits에 의해 제공된다; yield term structure를 위해 초기 date는 curve의 reference date에 대응한다. 초기값은 underlying data의 선택에따라 달라진다; discount factors를 위해 1, zero or forward rates를 위해 더미값(bootstrap procedure가 진행되는 동안 overwritten될 것이다)이 설정된다. 다른 노드들을 위한 dates는 대응되는 helpers의 latest needed dates이다; times는 이용가능한 curve facilities를 사용함으로써 구할수 있다.

이시점에서 각 노드(appendix A에 자세히 나온다)에서 사용하고 실제 bootstrap을 시작할 one-dimensional solver를 instantiate할 것이다. 계산은 두개의 nested loops로 작성된다; 각 노드에서 수행되는 inner one(bootstrap proper)과 프로세스를 반복하는 outer one. Iterative bootstrap은 non-local interpolation(cubic splines와 같은)이 사용될때 필요하다. 이 경우 노드의 값을 설정하는 것은 전의 노드를 무효화하면서 전체의 curve를 수정한다; 그러므로 convergence가 일어날 때까지 노드를 계속 주시해야만한다.
전에 말했듯이 inner loop는 각 노드를 돌아다닌다-물론 earliest date부터 시작한다. 첫번째 iteration(when iteration == 0)동안 interpolation은 한번에 한 point씩 확장한다; later iterations는 full data range를 사용한다 그래서 이전 결과는 starting point와 refined로서 사용된다. 각 노드가 추가된 후에, one-dimensional root-finding 알고리즘은 대응되는 시장 quote를 reproduce(재생산)하기 위해 사용된다. 첫번째 iteration을 위해, guess for the solution은 bootstrap traits 혹은 지금까지 built된 curve를 extrapolating하는 것에 의해 제공될 수 있다; 앞으로의 iteration을 위해, 이전의 결과는 guess로 사용된다. 최대/최소값은 이미 bootstrap된 노드를 기반으로 한 traits에 의해 제공된다. 예를 들면, bootstrapping zero 혹은 forward rates를 위한 traits는 최소값을 0으로 설정함으로써 음수값을 방지할 수 있다; discount factors를 위한 traits는 discounts가 증가하지 않도록 함으로써 같은 것을 할수 있다, 즉 이전 노드에서 discount를 최대로 셋팅하게 함으로서.
root-finding 알고리즘에서 딱 하나 빠진것은 zero는 반드시 찾아져야만 하는 기능이다. 이것은 BootstrapError class template(shown in listing 3.11)에 나온다. 이것은 helper's quoteError 계산을 function-object interface로 채택한다. 생성자는 만들어지고 있는 curve, 현재노드를 위한 helper 그리고 node index를 취하고 저장한다. operator()는 functions로써 사용될수 있는 class의 인스턴스를 만든다; node value를 위한 guess를 취하고 curve data를 수정하며 quote error를 리턴한다.

이 시점에서 모든것이 set된다. inner bootstrap loop는 BootstrapError 인스턴스를 생성하고 이것을 error가 zero인 것을 위한 노드 value를 리턴하는 solver로 보낸다. 즉 implied quote가 market quote와 같은 것(within accuracy)을 위해. curve 데이터는 리턴된 값을 포함하기 위해 업데이트 되고, 루프는 다음 노드로 진행한다.





남은 machinery(interpolated curves, piecewise bootstrap 등)은 설명한 다른 curves와 비슷하다. zero-coupon과 year-on-year rates를 위한 separate sub-hirarchies때문에, 여러 다른 점이 있다. 반면 discounts를 위한 ZeroStructure라던지 default probabilities를 위한 HazardRateStructure와 같은 single underlying quantity를 기반으로하는 whole interface를 구현하는 adapter classes는 없다. 반면, piecewise curves는 underlying quantity(예를 들면, in PiecewiseYieldCurve<Discount, LogLinear>)를 선택하기 위해 traits를 사용하지 않는다. 선택하기 위해서 적절한 class를 선택해야만 할것이고 PiecewiseZeroInflation<Linear>와 같은 것을 작성해야 할 것이다.

3.3.3 Volatility term structures