[奇妙なクラスと実世界]
2.銀行アプリケーションの事例
2.3 実世界そのままを表現したモデル
ここまでの話で、オブジェクト指向が描くモデルがいかに現実離れしたものであるかを理解していただけたかと思います。
そこで次は、「銀行アプリケーションの本来の現実世界」をモデル化してみましょう。
これは銀行に限った話ではありませんが、現代の銀行にはコンピュータ・システムの存在が不可欠です。したがって現実の銀行業務の多くはコンピュータにより自動化されており、「コンピュータによる実現手段は無視して現実世界をそのまま捉える」と言われても、どう考えたら良いか困ってしまいます。
そこで、ここではコンピュータが一切存在しなかった明治時代の銀行をモデル化してみることにします。
図2にこの明治時代の銀行モデルを示します。
ここでは、次のようなクラスを導出しました。
その銀行に勤務する職員。
実際に顧客と対応し、取引を遂行するのは銀行員であるあるため、基本的にすべての振る舞いは銀行員に対して定義される。
顧客の情報を記録した台帳。
ここでは台帳そのものではなく、台帳に記録された顧客ひとりひとり顧客情報をインスタンスとして捉えている。
顧客毎の取引内容を記録する通帳。
顧客との取引内容を記録した金銭出納帳。
ここでも同様に、金銭出納帳そのものではなく、そこに書かれた個々の取引記録をインスタンスとして捉えている。
また属性の「顧客名」は、顧客台帳に記されたものと一致している必要があるが、この整合性管理は台帳同士が自動的に行うのではなく、銀行員の責任であるため、関連ではなく、属性として表現されている。
壁に掛けてあるカレンダー。
月ごとの日数やうるう年、祝祭日に加えて、銀行の休業日などの情報も属性として保持する。
四則演算を行うための算盤。
このモデルには次のような注目すべき点があります。
(1) 銀行員だけが振る舞いを持っている。
「算盤」クラスが四則演算の振る舞いを持っていることを除いて、基本的にすべての振る舞いは「銀行員」クラスに定義されています。
(2) 属性がすべて公開されている。
「顧客台帳」「金銭出納帳」「カレンダー」などのクラスに定義されている属性はすべてpublic指定されており、外部に対して公開されています。
実際にも現実世界においては非公開にする属性はほとんどないのです。このような例として「暗証番号」が思いつきますが、これとて、もし完全に非公開だったとしたら誰も暗証番号の妥当性検査をすることができないでしょう。
実際に現実世界で何らかの振る舞いをするのは、ほとんどが人間ですから、このモデルは現実世界を良く表現しているように思えます。
さてこのモデルをそのまま設計・実装するとどうなるでしょうか?
「顧客台帳」「金銭出納帳」「カレンダー」といったクラスはデータベースあるいはファイルとして実装することができます。
アプリケーション・ロジックの多くは「銀行員」クラスのメソッドの中に記述されることになるでしょう。
「算盤」クラスのメソッドは四則演算用のサブルーチンとして実装できますが、算盤で可能な程度のアルゴリズムならば、ほとんどのプログラム言語では命令として直接記述できるでしょうから、あえてクラスとして実装する必要性はないかもしれません。
どうでしょう?
このようにすれば「現実世界をそのままモデル化し、実装した」と言えるのではないでしょうか?
しかしこれでは「銀行員」クラスにだけロジックが集中し、肥大化してしまうことは明らかです。
結果として、保守性や柔軟性は極端に悪化するでしょう。
ソフトウェア構造の観点からすると、現実世界との対比では奇妙なモデルであっても、先ほどのオブジェクト指向によるモデルを採用した方が、明らかに優れているようです。
© 1999 OGIS-RI Co., Ltd. |
|