[Contribution to Japan PLoP]
株式会社 オージス総研
オブジェクトテクノロジー・ソリューション部
平澤 章
この多国通貨パターンも、RDBパターン の時と同様にDeja vu（デジャブ）を元に書きました。
すなわち、これまでいくつかビジネスアプリケーションの開発をしてきましたが、そのときに感じたDeja vu、平たく言えば「あっ、これ前とまったく同じだ！」を、パターンの形式で記述したものです。
実際に分析や設計をするときに、すべてが新しい経験であることはほとんどありません。新しい仕事を担当するときには未知の技術や知識をたくさん学ぶ（＆学ばなければならない）のですが、その一方で「この設計は以前もやったことがある」「どこかで同じようなモデルに出会ったことがある」と感じることも多いものです。
ここで紹介する通貨モデルはそうしたDeja vuの典型例です。
これまで経験したビジネスアプリケーションの分析の中で、多国通貨を表現する概念モデルに何回か出会いましたが、それらは驚くほどよく似たものでした。その点で少なくとも、私の中では「パターン」として定着しているものです。
実際にはプロジェクトによって「基準通貨の変更まで考慮するか」「複数の市場を考慮するか」といった、関心の範囲あるいは柔軟性の考え方に差がありました。しかしそのような違いを経験したことで、かえって自分自身の中でこのモデルについてより深い考察ができたように思います。
多国通貨パターンでは、ビジネスアプリケーションなどで複数の通貨を取り扱う場合の概念モデルを記述しています。
記述方法は、はじめに単純なモデルを紹介し、考慮すべき要素をどんどん追加していくことで、だんだんと複雑なモデルに発展させていく形式を取りました。これは
Martin
Fowler の「アナリシスパターン」
に倣ったものです。
（もっとも「アナリシスパターン」の改訂版では、このようなストーリー形式だけでなく、「リファクタリング」に書かれたようなカタログ集も併記する形式に変更されるようです。さらに
Java
によるコードサンプル（！）まで書かれています。もっとも
Fowler
氏本人のコメントによると、出版は早くとも２００１年の後半になるそうですが。興味のある方は、こちらをどうぞ。）
また通貨のモデリングだけでなく、より抽象度を上げて一般的な単位にも使えるパターンにできないか、とも考えました。しかし通貨の他に、時間や場所により相対価値が変化する単位の例を思いつかなかったため、結局通貨に焦点を絞った書き方にしました。（もし思いついたならば、パターン名は"Variable Ratio"にしたかったのですが！）
そのため内容的には、さまざまな場面で使える汎用的な考え方というよりも、通貨についてのモデリングの実例紹介という面が強くなっています。
ただし、それだけでは面白くないので、いくつかの工夫をしました。
１つ目は、「アナリシスパターン」に登場する「量(Quantity)パターン」との対比です。
Quantityパターンでは、「基準単位」クラスがないのですが、通貨では「基準通貨」という概念が一般的であることから、この概念を当てはめることで、Quantityパターンを発展（ただの変形？）できることを記述しました。
２つ目は、概念モデリングの表現方法についての議論の記述です。
概念モデリングでは、いわゆる設計判断をする必要がなく、自分達が理解したことをそのままクラス図として表現すればよいため、ある意味で非常に気軽にモデルを書くことができます。しかし一方で、「人が理解するためのモデル」であるがゆえに、「厳密さ」と「簡潔さ」そして「理解しやすさ」の３つをバランスよく表現しなければなりません。これは実際には簡単なことではありません。このために概念モデリング作業のまとめをする場面では、しばしばモデルの表現方法について悩むことがあります。
実際に今回、パターン記述に載せるクラス図を考えたときにも、どれを選ぶべきかしばしば悩む羽目に陥りました。そして、今回は思いきってその「悩み」をそのまま書いてしまうことにしました。つまり、どれを選ぶべきか悩んだクラス図は、基本的にすべて掲載することにしたのです。
今回は、アナリシスパターンとして書いたので、実装については何も触れませんでした。
これはこれで話としては完結しているので、まあ良いかなとは思っているのですが、実装までを示していないことについてはエンジニアとして少し後ろめたさを感じています。（これについてはまた別の機会に整理してまとめてみたいと考えているのですが．．．）。とりあえず以下に、多国通貨パターンを実装する上でポイントとなる点について、いくつか思いつく限りを書いておきます。
通貨オブジェクトは、クライアントが毎回生成する値オブジェクトではなく、必要なインスタンスを一元管理する参照オブジェクトとするのが一般的でしょう。（参照オブジェクトと値オブジェクトの違いについては、やはり Martin Fowler による「UMLモデリングのエッセンス（第２版）」の６．８節で議論されています。）
このためには、通貨オブジェクトを一元管理するオブジェクト(CurrencyHolder)を用意する必要があります。
この管理オブジェクトは、Singleton
として実装するのが一般的で、その場合のクラス図は次のようになります。
2) 基準通貨の実装
「多国通貨パターン」では、いくつかのモデルで基準通貨を通貨のサブクラスとして表現しました。
これは概念モデル上、「関心のある通貨のうち、特殊な１つが基準通貨であること」を、継承のノーテーションを使って表現したのですが、必ずしも実装する上で継承を使うことを意図したものではありません。
実装上、基準通貨をサブクラスにしない設計としては、次のように通貨の管理オブジェクトに基準通貨の管理も行わせる方法が考えられます。（ここでは、基準通貨の管理の責任も持たせたため、名前も CurrencyHolder から CurrencyMgr に変更しました。）
通常、概念モデルではクラスの責務までは定義しません（少なくとも私はそう心がけています）。しかし、設計段階では、どのクラスにどのような役割を持たせるかを決め、メソッドを定義していく必要があります。
通貨の例で言えば、異なる通貨の金額同士を計算するためのメソッドをどこに持たせるかが、設計上の１つの重要なポイントになります。これは基本的には、Moneyに持たせるのが自然でしょう。
しかし、複数市場までを考慮したモデルあたりになると、日付や市場までを指定しないとレートが定まらないため、金額計算はできません。そのような場合に Money クラスに金額計算の責任を持たせると、Moneyクラスのメソッドが大きくなりすぎてしまうかもしれません。そのような場合には、MoneyCalculator といったクラスを用意して、そこに計算をさせるのも１つの方法です。
金額計算の結果としての Money オブジェクトの返し方についても考えておく必要があります。
基本的には、金額計算メソッドの中で新しく Money オブジェクトを生成する方法と、計算の対象になる Money オブジェクトを変更してしまう２つの方法が考えられます。
前者は、金額計算のたびにオブジェクトが生成されてしまうため、パフォーマンス的に不利になります。金額計算の対象が多い場合は、レスポンスタイム悪化の原因になるかもしれません。一方、Money オブジェクトを変更不可にできるため、安全性は高いと言えます。
後者は、前者の裏返しで、パフォーマンスで有利な反面、既存の Money オブジェクトが変更されるため、使い方を間違えると思わぬ副作用が起きる心配があります。
基本的には、前者、すなわち毎回 Money オブジェクトを生成する方法を採用すべきでしょう。ただし、それによるパフォーマンス上の問題が大きい場合は、後者に変更する必要があるかもしれません。
通貨にレートを保持させるとして、どのように持たせるか考慮する必要があります。
単一市場だけに関心がある場合、レートは期間で一意に決まります。期間の管理単位が、月や日などで一意に決まる場合は、その期間をキーとしてハッシュテーブルで保持する方法が良いでしょう。
単一市場だけに関心があるとしても、期間の管理単位が一意でない場合は、このようなことはできません。その場合レートは順序つきコレクション（Vector など） で保持し、検索要求があった場合に、最新のレートからさかのぼって該当レートを見つける方法が有力でしょう。
Java2で提供される SortedMap のようなコレクションを利用すれば、上記の両方、すなわちキーによるアクセスとキー順序によるアクセスの両方が可能になります。
なお参考までに、日経ソフトウェア９月号（2000年7月発売）のオブジェクト指向特集において、この多国通貨モデルを例に取って、非常に単純な分析・設計・実装の記事を書きました。この時作ったクラス図と Visual Basic のサンプルコードを以下に置いておきます。
ダウンロードはこちら (NikkeiSoft.zip, 20KB)
私自身、以前はこのような自分の経験から得た知識をパターンとして外部に公開してしまうことについては懐疑的に考えていました。ノウハウは企業や個人の内部に蓄えておくからこそのもので、外部に公開してしまえば価値がなくなると考えていたからです。
しかし実際に Japan PLoP にパターンを投稿した経験を通じて、その考えが必ずしも正しくないことに気づきました。
パターンとしてまとめることは、何よりも自分にとってメリットがあります。パターンを書くことで自分の知識を整理できますが、その過程でそれまでの考慮漏れや思い違いを発見することも非常によくあります。
またパターンはある程度決まった形式が用意されているため、書きやすいものです。少なくとも自分でアウトラインから考えるよりはよっぽど楽です。明確な形式に沿っていることは読む人にとっても読みやすいのではないでしょうか。
そしてパターンを公開する何よりのメリットは、人から意見やコメントをもらえることです。みなさんもシステム開発をされるときにはいろいろな工夫をされていると思いますが、多くの場合それに対するフィードバックを得られる対象は同僚、上司、顧客ぐらいのものでしょう。不特定多数の人から、さまざまな観点で出されるコメントは非常に興味深いものです。しばしば自分の意図がきちんと通じていないことがわかる場合もありますが、これとても自分の表現力や文章表現やまずさ、あるいは無意識に持っている前提事項に気づかせられる点で有益なものです。
何もないところからパターンを見つけるのは容易ではありません。
しかし実際のシステム開発経験を通じて同じような解決策に出会うことは、非常によくあることです。このような
Deja vu はパターンの素です。まず自分の覚え書きとして、気軽に始めませんか？
Deja vu に出会ったらパターンを書きましょう！
| © 1999 OGIS-RI Co., Ltd. |
|
