ObectSquare

[奇妙なクラスと実世界]


2.銀行アプリケーションの事例

2.3 実世界そのままを表現したモデル


ここまでの話で、オブジェクト指向が描くモデルがいかに現実離れしたものであるかを理解していただけたかと思います。
そこで次は、「銀行アプリケーションの本来の現実世界」をモデル化してみましょう。

これは銀行に限った話ではありませんが、現代の銀行にはコンピュータ・システムの存在が不可欠です。したがって現実の銀行業務の多くはコンピュータにより自動化されており、「コンピュータによる実現手段は無視して現実世界をそのまま捉える」と言われても、どう考えたら良いか困ってしまいます。
そこで、ここではコンピュータが一切存在しなかった明治時代の銀行をモデル化してみることにします。
図2にこの明治時代の銀行モデルを示します。

 

ここでは、次のようなクラスを導出しました。

このモデルには次のような注目すべき点があります。

  (1) 銀行員だけが振る舞いを持っている。

「算盤」クラスが四則演算の振る舞いを持っていることを除いて、基本的にすべての振る舞いは「銀行員」クラスに定義されています。

  (2) 属性がすべて公開されている。

「顧客台帳」「金銭出納帳」「カレンダー」などのクラスに定義されている属性はすべてpublic指定されており、外部に対して公開されています。
実際にも現実世界においては非公開にする属性はほとんどないのです。このような例として「暗証番号」が思いつきますが、これとて、もし完全に非公開だったとしたら誰も暗証番号の妥当性検査をすることができないでしょう。

実際に現実世界で何らかの振る舞いをするのは、ほとんどが人間ですから、このモデルは現実世界を良く表現しているように思えます。

さてこのモデルをそのまま設計・実装するとどうなるでしょうか?
「顧客台帳」「金銭出納帳」「カレンダー」といったクラスはデータベースあるいはファイルとして実装することができます。
アプリケーション・ロジックの多くは「銀行員」クラスのメソッドの中に記述されることになるでしょう。
「算盤」クラスのメソッドは四則演算用のサブルーチンとして実装できますが、算盤で可能な程度のアルゴリズムならば、ほとんどのプログラム言語では命令として直接記述できるでしょうから、あえてクラスとして実装する必要性はないかもしれません。

どうでしょう?
このようにすれば「現実世界をそのままモデル化し、実装した」と言えるのではないでしょうか?
しかしこれでは「銀行員」クラスにだけロジックが集中し、肥大化してしまうことは明らかです。
結果として、保守性や柔軟性は極端に悪化するでしょう。

ソフトウェア構造の観点からすると、現実世界との対比では奇妙なモデルであっても、先ほどのオブジェクト指向によるモデルを採用した方が、明らかに優れているようです。


© 1999 OGIS-RI Co., Ltd.

Prev.

Index

Next