内、BlackIborCouponPricerクラスの実装内容の一部を示します。Blackモデルを使ってそれらの計算を行っている所から来ています。使われることはありません。することによってチェックします。うまくいけば、いくつかの事前計算を行います。ここでは、概要を知っていただくために、クーポンの倍率とスプレッドの情報をメンバー変数に保存しているコードをお見せしています。これを見ていただければ、他のメソッドをより正確にプログラミングする助けになると思います。)メソッドで計算された‘調整後金利’に単純に倍率を掛け、スプレッドを足しています。そのまま使うだけです。された金利に加えられます。ボラティリティのデータチェックの部分だけ示しています。)メソッドなど、他の金利を返すメソッドの実装内容については、ここでは省略します。Libraryのプログラムコードを直接読んで確認して下さい。(何でもバラバラに分解するのが好きな子供向きではないかも知れませんが)、単純な変動金利キャッシュフローを持つ変動金利債の価格計算で使われる一般的な実務慣行です。プログラムコードを自分で書き換えたく無い人にとってはこれで十分かと思います。モデルLibraryは、この方法を取るか取らないか選択肢を持つべきであり、その場合は、少なくとも2つの方法が用意されています。Overrideする方法です。Par金利を使って計算値が返されます。実際の計算を依存していますが)をそのまま使います。};この方法は、そのままで動きますが、いくつか欠点もあります。Pricerを設定する事もできますが、目に見える効果はありません。fixing金利を使ってしまう可能性があります。その結果、両者の同一性が失われ、最悪間違ったヘッジ比率を計算してしまう可能性があります。別途外生的に実装してしまう方法かもしれません。Pricerを作るなら、BlackIborCouponPricerクラスから派生させて実装する事が出来ます。する必要があるだけです。(訳注:イールドカーブから、市場実勢のLIBOR金利を導出すること)。Pricerの選択が可能になります。};しかし、この方法でもまだ1点問題があります。(訳注:メソッドの名前と、実際の計算内容が違う)。Overrideする場合にも発生しています。これといった明確なアイデアがありません。Overrideして、Par金利を取り込んで、Nullの調整値を返すことです。この方法は金利後決めのケースではうまくいきません。)に変えてしまうことですが、こうすると、逆に何を意味しているか解りにくくなってしまいます。Adjustmentの計算をPricerにまかせてしまう方法です。)メソッドの説明の際に指摘した脆弱性の問題の解決策になるかも知れません。現時点の実装方法はどうかと言えば、若干問題ありでしょう。次のAsideの項をお読みください。Par金利を取ってきてそれを返すものです。ある意味、それで事足りています。(後者については、他の実装方法では、そうなっていないので、それが今の方法を選択したひとつの理由です。)しかし、やはり実装方法としては間違っています。メソッドの名前の通りの内容になっていないからです。fixing金利を返していません。今後のリリースで、プログラムコードを修正すべきであり、クラスのメソッドがその宣言通りの意味を持たせるべきです。様々な変動金利クーポンにしばしば付いている条件です。派生クラスで加えたいと思っています。いった要求を満たすには、Decoratorパターンを使うのがふさわしいでしょう。Decoratorパターンの典型的な様式に従っています。FloatingRateCouponインスタンスに対するポインターを保持した上で、必要な追加動作(メソッド)を実装したり、あるいは保持したポインターを使ってベースクラスのメソッドを使ったりします。C++では、他の言語と違って、Decoratorパターンを実装する為の他の方法も用意されている点に注意下さい。テンプレートと派生クラスを一緒に使って、次のようなコードを書くことも可能なのです。いったインスタンスを生成し、これらのクラスの中で必要な追加動作を実装したり、ベースクラスで用意されているメソッドを呼び出したりすることが可能です。使う方法に変更する強い理由は見当たりません。CappedFlooredCouponクラスを説明する中で、仮にクラスTemplate方式を使った場合の、良い点、悪い点などの相違点も説明していきます。取り、メンバー変数に保持しています。FloatingRateCouponクラスのコンストラクターに渡して、自らのメンバー変数として保持していることです。Decoratorパターンの実装方法とは、少し離れています。Couponインスタンスのインターフェースを使って、そのインスタンスのメンバーデータを使うようにするでしょう。}今の実装方法は、あえてこのようにせず、(Decorateする為に作られたオブジェクトが)自分自身で(Decorateの対象となる)Coupon情報を保持して、それを使っています。)メソッドは、コピーされたメンバー変数をそのまま返しているだけです。その結果、いくつかの情報は2重に保持している事になり、最適とは言えません。一方で、こうする事によって、ポインターを使った何件ものメソッドの呼び出しを避けることができます。別の方法を取るとすれば、Couponクラスのメソッドをすべて仮想関数として宣言し、すべてOverrideする方法です。派生させる方法を使ったとしたら、プログラムのデザインはもう少し簡潔になったかも知れません。自分自身であり、情報を2重に保持するといった状態は避けられます。その場合でも、コンストラクターは、情報をコピーせざるを得ないのです。...これはより望ましい方法とは言えません。Couponオブジェクトのインスタンスを生成するのに必要な引数を取るため、別途それを外生的に構築してから引数として渡し、データをコピーし、使用後は消去しなければならないのです。1ダース程度のテンプレートコンストラクターを用意する必要がある為です。よって、それぞれこの問題は解決できるかも知れません。従って、将来的には、このデザインを見直すかもしれません。引数として渡されます。2ステップほど操作をしています。付いているかどうかのフラッグになります。他の箇所で行っている方法とは若干異なります。使ってデータが使われているかどうかチェックしています。Bool変数を保持するのは二度手間のように見えますが、Null値を魔法の数字のように使うのを避けています。ような型を使う方が良かったかも知れません。Null値を保持することになりますが、意図が言葉上より明確です。変更したいのですが、現段階ではそれに依存するコードが膨大にあるため躊躇しています。一つの操作は、Cap金利は最大金利として保持されているとは限らないという事です。メンバー変数に保持されます。いうクーポン計算式になるが、この場合、倍率の前の符号がマイナスになっている。この方法は、コンストラクターとインスペクター関数にとって複雑で紛らわしい操作を要求します。引数をそのままそれぞれのメンバー変数に保持する方が良かったかも知れません。Couponインスタンスのメソッドの内、まさにDecorateされる部分です。加え、Caplet金利を引くことによって調整するようになっています。委託されていますが、引数として実効Cap金利と実効Floor金利を必要とします。この後でみていきますが、これらの実効CAP金利や実効Floor金利は対象金利インデックスに適用になるものであり、Couponレートそのもの適用になるものではありません。使った継承の方法を使ったとすれば、このような動作を何のコストも払わずに取り込めました)。Convexity調整が必要になりそうなので、少し変に見えます。fixingレートを調整するためのものだからです。(コンストラクターが入れ替えたものを基に戻すため)、それぞれ返します。Floor金利を保持する時に、コンストラクターが入れ替えの操作を行わないように改良すれば、この操作は不要になります。)メソッドの中で実行してもいいかも知れません。Floor金利を返しています。)メソッドについてです。インスタンスの両方にセットされます。若干問題がありそうに見えます。Decoratorパターンを素直に使っていれば、あるいはクラスTemplateからの派生クラスを使っていれば、Pricerの保持が重複している部分と、必要以上の動作を行っている部分は、不要であったかもしれません。これまでにプログラム開発者としてもっとひどい罪を犯してきたものとしては、このメソッドの中だけに起こっているこの程度の重複はお許し頂きたいと思います。これで、CappedFlooredCouponクラスは完成です。Couponクラスのインスタンスを簡単に生成する事が可能です。LIBORインデックスによる変動金利クーポンをベースクラスから派生させたものです。このクラスはコンストラクターを定義しているだけです。IborCoupon(...)の部分)、それをベースクラスのコンストラクターに渡しています。この方法により、Couponクラスを(外生的に)生成するための面倒な作業を無くしています。仮に、CappedFlooredCouponクラスをクラスTemplateの形で設計していたとしても、この実装内容は全く同じになります。};最後に、ありうる別の実装方法についてです。Bool変数と、どちらが使われているのかを追跡するロジックをコード化する必要があります。作れば、この作業は避けることが出来るかもしれません。変数を保持する必要なくなります。構築することは、ある程度のプログラムコードの重複は避けられないでしょう。とそれを管理するためのロジックの構築も必要になるでしょう。読者の方が、その方法による実装を試したいのなら歓迎します。今の実装方法との比較についてどうなるのか、教えて頂けることを歓迎します。キャッシュフロー配列の生成Couponキャッシュフローが一本しかないケースは稀です。普通は、Couponは連続したキャッシュフローの塊として存在し、それが故に、モデルライブラリーの設計者の頭痛の種になります。構築するような機能を提供したいと思っていましたが、そうする為に、いくつかのインターフェース上の問題に直面しました。最初に、我々はそのような機能を、一番手っ取り早い方法でプログラムしてみました。構築し、そのインスタンスを返すという、自己完結する関数です。呼び出すには使いにくいものでした。構築するためには、ユーザーは次のようなプログラムコードを書かなければなりません。true);上記のコードは2つの問題を抱えています。1%、金利決定が後決め、といった情報を渡していますが、上のコードからそれが簡単に推察できるでしょうか?)。この問題は、次のコードのように引数に名前をつければ若干和らげることができます。true;しかし、こうすると関数を呼び出す前に各引数の定義を行わなければならず、プログラムコードが冗長になります。(訳注:デフォールト値が使えなくなるので関数呼び出し時に値を与えないといけなくなる)。null値の配列を、引数として渡す必要があります。ふたつ目の問題は、我々のドメイン特有のものです。Coupon毎に異なるケースがあります。スケジュールが付いているような条件では、Coupon毎に減少していきます。(CapやFloorの金利が一定ではなく)、フォワード金利に沿うような形で決まっているものもあります。Couponキャッシュフローを構築する関数は、できるだけ汎用的にするために、そのような引数はすべて配列で取り込む必要があります。そのような引数が、仮に一定であったとしても、コードが冗長になってしまいますが、配列を生成せざるを得ません。そのようなケースが大半にもかかわらず。引数が増えれば、あっという間にその数は管理できないほど大きな数になってしまいます。)あるひとつの方法が、両方の問題を解決します。中で、すでに常用されている慣用句として紹介されています。呼ばれていた人気の高い手法でした(下記[2]参照)。考え方は極めて単純です。Couponの配列を構築しようとするものです。関数のように、呼び出しの際にすべての引数を一度に渡そうとするのではなく、引数ごとに解りやすい名前のついたメソッドで数値を渡していくものです。この方法を使うと、下記のコードのように、すでに紹介した関数による呼び出しよりも、より少ないプログラムコードで、かつ意味が明瞭な方法で同じ動作が行えます。}コンストラクターは、デフォールト値を与える意味があまりなく、同じような型の他の引数と混同する余地が少ない引数を2つ取るのみです。その他のメンバー変数は一旦、固定されたデフォールト値か、引数として渡された値を基に設定されます。DayCounterオブジェクトを使います。)それ以外の引数は、setter(パラメータを設定するメソッド)関数を使って、引き渡されます。setter関数は、その意味が明確な関数名が付けられ、引数として単一の値をとる場合と配列を取る場合に分けてオーバーロードされています。個のオーバーロード関数が必要になりますが、それでもこの方法の方が他の選択肢よりも管理しやすいと思います。IborLegインスタンスへの参照を返す事によって、並べて実行できるようにしています。Couponインスタンスの配列を生成します。(それ自体はそれほど興味を引く話題ではありません。IborLegオブジェクトに保持された日付や配列の中身を使って、Couponインスタンスの配列を生成します。)最後に、一点追加で注意点を述べたいと思います。本件の実装ではなく、Boostライブラリの開発者グループが同じ問題を解決する別の方法を提供してくれました。名前付きパラメータを使うことが可能にしました。ベースにした実装もきちんと機能しており、開発者にとっても負担が少ないものです。解決策が本当に素晴らしいものである事を、紹介したかっただけです。Coupon配列を、ここで説明したような形で実装することも可能です。Couponキャッシュフローに拡張可能です。オブジェクトモデルを提供しています。使っている所が異なるのみです。Couponキャッシュフローを生成するような事も出来るかもしれませんので、読者の方に試して頂きたいものです。Couponキャッシュフローにも同じオブジェクトモデルが使えます。Couponキャッシュフローについては、既に実装済みです。Couponキャッシュフローについても応用可能かという質問を投げかけています。私としては、クラスのデザインを変える前に、そのような実例が出てくるのをもう少し待ちたいと思います。<ライセンス表示>QuantLibのソースコードを使う場合は、ライセンス表示とDisclaimerの表示が義務付けられているので、添付します。