縦でも横でもないマトリックスで構造化
| ||
| ||
|
そこで，機能でもデータでもなく，意味的に関連する機能とデータのまとまりで構造化しようというのがオブジェクト指向の考え方です。別の言い方をすれば，縦方向でも横方向でもなく「クラス」という小さなマトリックスの単位でシステムを構造化しようということです1。システム内の全機能とデータでマトリックスを作り，依存し合うものをそばに配置してクラスとして「対角化」してやろう，という発想です（図2[拡大表示]）。逆に，この操作でうまく小マトリックスの塊が見出せなければ，その問題領域をオブジェクト指向ではうまく解析できないということです。マトリックス全体をハンドリングするような別の方策，例えばルール指向や状態イベント・マトリックスなどによるモデル化を考えることになります2。ただし人間にとって，その問題領域の理解という点ではオブジェクト指向に劣るのを甘受する必要があります。
オブジェクト指向のすごいところはこの先にあります。小行列化して管理対象にしたクラスを「ソフトウェア・モジュール」であると同時に「型（タイプ）」でもあり，問題領域のモデルを構成する「概念（コンセプト）」でもある，としたのです。少々の齟齬には目をつぶって，「クラス＝モジュール＝型＝概念」の方程式が成り立つと宣言してしまったのです。
これこそオブジェクト指向のソフトウェア世界における成功を約束したものです。モジュールであるから，ソフトウェア工学の基本的対象としての地位を確保できます。またデータ型なので，古典的なプログラミング言語のなかでも位置付けが可能です。なおかつ概念クラスとしてモデルで位置付けられるので，開発の上流におけるビジネス・モデリングや要求分析にまで触手を伸ばせるようになったのです。この方程式を編み出した人間は天才です。
もう聞き飽きたと思いますので，オブジェクト指向の基本中の基本である，「関係するデータと手続きのカプセル化」「クラスによるオブジェクトの抽象化」「汎化（継承）によるクラス分類」「関連によるオブジェクトの参照」「集約による全体部分管理（コンポジット）」および「ポリモルフィズム（多義性/多相性/多態性）によるインタフェース実現」の説明は端折ります。よくわかっていないという方は，同僚の棚の上に並んでいるであろうオブジェクト指向かUMLの入門書でさっと勉強してみてください。
ただ既存の入門書では，自律した状態マシンとしてのオブジェクトという観点が弱いのでそれを補う必要があります（図3[拡大表示]）。複数の自律オブジェクトが互いにメッセージの送受信により内部状態を遷移しながら対応するアクションを実行し，その副作用としてオブジェクトのネットワーク全体でシステムとしての機能を発揮するという見方です。この観点の延長上にエージェント指向があります。
インタフェース遵守が大事
ここまでで見えてきた「オブジェクト指向的」なるものを見極めるため，ソフトウェア工学的に妥当なモジュールのデザイン原理と呼ばれるものをいくつか見てみましょう3 4。以下のようなものがあります。
(1)変更の影響が小さい，分解しやすい
(2)よく考えられたインタフェースで，組み合わせやすい
(3)関連するデータと機能が局所化されて凝集度が高く，理解・保守しやすい
(4)各モジュール間の結合度が極小化されている
(5)明示的で小さいインタフェースをもつ
(6)型の変化やデータ構造・アルゴリズムの変更に対応しやすい
以上の要請に対するオブジェクト指向からの回答が，「開放閉鎖モジュールとしてのオブジェクト」原理です（図4[拡大表示]）。「外部にはインタフェースとして抽象クラスだけを公開し，データ構造や機能は抽象クラスのインタフェースを守るためそのサブクラスとして実装しましょう」という原則です。これにより，「既存のクラスを修正せずにシステムに新しい機能を追加できる」「既存コードに手を入れずに新たなデータ構造やアルゴリズムを追加できる」ようになります。この原理は「クラス抽象化」「カプセル化」「継承」「ポリモルフィズム」をすべて結びつけるオブジェクト指向のエッセンスです。実際，ほとんどのデザイン・パターンはこの原則から導出できるものです。
この原理は，オブジェクト指向では個々のデータやアルゴリズムよりもインタフェースが重要ということを意味しています。それを裏で支えるのがカプセル化であり，継承とポリモルフィズムである，というわけです。
ボトムアップではなく普遍性に目を向ける
オブジェクト指向ではデータ中心と違い，データではなく概念に着目してシステムを構造化します。従って個々のデータ項目からボトムアップにクラスを識別するのではありません。あくまでも対象領域全体の中での意味や役割を問題にします。例えば販売行為という大きな視点でみたとき，そこには「小売店←（販売）→顧客」という対立構造が存在します。その構造の役割要素として「小売店」や「顧客」が識別されるのです。ここで販売とは「販売者と顧客における『製品』と金銭の交換」という構造が認識できれば，小売店とサービス提供会社の共通性が浮かび上がってきます。そして製品とサービスを抽象クラス「商品」で表現しようとなるわけです。モデル全体におけるお互いの位置付けや相互規定から概念が導出されてくるわけです＊1。当然，各データ項目は，そうして識別された概念の妥当性の検証に利用されます。そして，概念としてのクラスの妥当性は，いかに普遍的で役に立つインタフェースが公開されているかによって判定されることになるのです。
オブジェクト指向のよいところは，ソフトウェアのどんな問題であっても対処できる点です。それを管理したいと認識しさえすれば，データだろうが処理だろうが型だろうが，モジュールだろうが拡張可能点だろうがドキュメントだろうが，なんでもオブジェクトとして統一的に管理できます。そしてプログラムの問題にできます。デザイン・パターンはそれを体系化したものです。これが非常に重要です。オブジェクトとは，その領域において問題として一つひとつ明確に管理しますよ，という観察者の表明そのものなのです。
羽生田 栄一 Hanyuda Eiiti豆蔵 取締役会長富士ゼロックス情報システム時代にSmalltalk-80システムに触れ，オブジェクト指向に開眼。以降オブジェクト指向技術の普及に努める。オージス総研を経て2001年にオブジェクト指向技術専業ベンダーである豆蔵の代表取締役社長に就任。2003年より現職。オブジェクト指向技術関連の訳書多数。技術士［情報工学部門］。 |
