 図5 オブジェクト指向における「クラス」と「継承」の概要 「クラス」とはオブジェクトに共通の性質を抜きだしてグループ化した，オブジェクトの「ひな型」である。一方，継承とは，上位クラス（スーパークラス）のメソッドや属性といった性質を引きついだ下位クラス（サブクラス）を定義して，新たな性質を追加することである。スーパークラスからサブクラス，そしてオブジェクトへと，より具体的な性質を定義する [画像のクリックで拡大表示] |
 図6 「ポリモルフィズム」の例 オブジェクト指向では，同じメッセージに対してオブジェクトごとに異なる処理を実行させることができる。これを「ポリモルフィズム」と呼ぶ。ポリモルフィズムを活用すれば，簡潔な構造で多様な処理を実行するシステムを開発できる [画像のクリックで拡大表示] |
似て非なる関数とメッセージ
現実の物事をソフトウエアに置き換えて，人間にとって扱いやすくする上で，カプセル化が必須だとお分かりいただけたと思う。では，オブジェクトに何らかの処理を実行させるにはどうすればよいのだろうか。
仮に関数を呼び出す方式ならば，オブジェクト内部に記述してある関数を直接指定することになる。これでは，カプセル化も何もあったものではない。
結局，オブジェクトに処理を実行させるには，先方のオブジェクトに「処理要求と最低限必要な情報を送って，後は先方のオブジェクト内部での処理結果を受け取る」といった方法をとるしかない。
これが「メッセージ・パッシング」である。オブジェクト指向の初心者にとっては，この「メッセージ・パッシング」がまたクセ者だ。NECの岸上信彦IT基盤システム開発事業部Java/XML技術センター長は，「関数呼び出しもメッセージ・パッシングも，プログラミング上の記述自体には大差ない。なぜ関数呼び出しやシステム・コールといった，コンピュータらしい用語を使わないのか，オブジェクト指向入門者がもっともぶつかりやすい疑問だ」と話す。しかし内部を隠蔽したオブジェクトに処理を実行させる方式は，「メッセージを送る」しかあり得ないのだ（図4参照）。
「クラス」も人間的思考の産物
「カプセル化」と「メッセージ・パッシング」。この2つが，オブジェクト指向のオブジェクト指向たるゆえんであることを説明してきた。
オブジェクト指向におけるもう1つの基本概念である「クラス」も，カプセル化と同じく極めて自然な考え方から生まれたものだ。クラスとはオブジェクトに共通のメソッドや属性を抜き出してグループ化した，オブジェクトの「ひな型」である。オブジェクトと違って，具体的な値を持たない。
なぜクラスが必要なのかと言えば，現実の物事を模する上で必須だからである。人間は無意識のうちに，物事をグループ化して考えるものだ。「受注伝票」，「発注伝票」と聞けば，自動的に「これらは『伝票』という大きなグループの一種なのだな」と思い浮かべるはずだ。この例では伝票がクラスである。
オブジェクト指向における「抽象化」とは，このような考え方を指す。抽象というと何となく「物事をあいまいにする」印象があるかもしれないが，むしろ逆である。共通点を見いだして，よりクリアに物事を見ようとしているのである。
クラスと裏腹の関係にあるのが「継承」だ。継承とは属性やメソッドといった，あるクラスの内容を引き継いだ別のクラスを定義すること。引き継ぎ元のクラスを「スーパークラス」，引き継いでできたクラスを「サブクラス」と呼ぶ。サブクラスは，スーパークラスのすべての属性，メソッドを備える（図5[拡大表示]）。
継承はクラスと逆の考え方をしていけば理解しやすい。同じ伝票である以上，受注伝票も発注伝票も「起票」や「登録」といった，伝票なら当然の処理ができると分かる。伝票クラスの内容を引き継いでいるからだ。また受注伝票は単なる伝票と違って，受注専門の処理が可能であることも，容易に想像がつくだろう。
継承には，プログラミングにおける現実的な利点もある。継承を使うと，プログラムの大半は既存のコードを使い，足りないコードだけを新たに書き足す「差分プログラミング」が可能になる。
「自然な考え」という視点で
「オブジェクト指向は人間にとって自然な考え方」。この視点に立てば，その他の用語も理解しやすい。
例えば「ポリモルフィズム（多相性）」。これは同じメッセージに対して，複数のオブジェクトにそれぞれ異なる処理を実行させることを指す。文字面だけを見ると何やら難解な印象を受けるかもしれない。
しかし現実の物事に当てはめてみれば，これまた自然であることが分かるだろう。現実の人間や物体は，同じメッセージを受け取ったとしても，人（物）よって異なる反応を示すことが当たり前である。ポリモルフィズムは，この現象をソフトウエアに当てはめただけだ。シンプルではあるが利点は大きい。WindowsやMacintoshのGUIは，このポリモルフィズムの好例である。GUIでは画面上のどのアイコン（＝オブジェクト）をダブルクリック（メッセージ送信）するかによって，コンピュータはそれぞれ異なる処理を実行する（図6[拡大表示]）。「ダブルクリック」という同じメッセージで，多様な処理を実現している。まさにこれがポリモルフィズムだ。
実践には「強制力」が必要
ここまで読み進んできて，オブジェクト指向に対する理解が深まったことと思う。その上で，もう1つ覚えてほしいポイントがある。それはオブジェクト指向のシステム開発を実践する際には，「オブジェクト指向を強く意識する必要がある」ということだ。
純粋なオブジェクト指向開発は今も難しい。オブジェクト指向言語やGUIを使ったとしても，結局コンピュータの内部は手続き指向に則っている。オブジェクト指向に“違反”しようと思えば，いくらでもできてしまうからだ。
例えば，システムの処理性能を優先して，プログラムからいきなりメモリー・アドレスを指定して直接アクセスすることも可能だ。データベースやミドルウエアなど，システム構築に欠かせないIT関連製品の中には，オブジェクト指向とは異なる旧来の構造を持つものも依然として多い。
SRA先端技術研究所の青木淳執行役員は，「オブジェクト指向を根本から理解し実践するには，ソフトウエア環境すべてを強制的にオブジェクト指向に統一するくらいのことをしないとダメだ」と断言する。
オブジェクト指向開発を成功に導くカギは，知識や技術の習得に加えて，“強い意志”を持つことだとも言えるだろう。
オブジェクト指向COBOLに注目
オブジェクト指向言語と言われて，読者の方が真っ先に思いつくのは，おそらくJavaやC++，C＃などだろう。しかし，もう1つ選択肢がある。それが「オブジェクト指向COBOL」だ。 2002年9月に，COBOLの新しいISO規格，いわゆる「COBOL2002」が賛成多数で承認された。COBOL2002とは，世界各国のCOBOLベンダーやユーザーからなる標準化委員会が，従来の規格を大幅に拡張して策定したものだ。最大の特徴が，言語仕様にオブジェクト指向を取り入れたことだ。オブジェクト指向COBOLは，日立製作所をはじめ計4社が，規格制定前の仕様を一部採用して製品化している（これらの製品間の互換性は低い）。 COBOL2002はオブジェクト指向言語として充分な機能を備えている（表A[拡大表示]）。「クラス」や「インタフェース」の定義はもちろん，メッセージ・パッシングによるメソッド呼び出し，あるクラスの性質を引き継ぐ「継承」，同じメッセージに対してオブジェクトごとに異なる処理を実行する「ポリモルフィズム」，不要なメモリーを自動的に解放する「ガーベジ・コレクション（GC）」などである。 プログラミングの効率を考えた場合，GCは非常に有効だ。プログラマ自身がメモリー管理に悩まずに済むからである。不要になったオブジェクトの消費メモリーを自動的に解放するGC機能は，オブジェクト指向プログラミングに必須といってよい。他の言語ではJavaやC＃はGC機能を備えているが，C++にはない。C++ではプログラミング上のさまざまな工夫を盛り込んでいるが，やはりメモリー解放漏れ（メモリー・リーク）に関するバグが残りやすい。 複数のクラスの性質を引き継ぐ「多重継承」を備えている点も，COBOL2002の特徴である。一方，現在オブジェクト指向プログラミング言語の主流であるJavaは，多重継承を認めていない。 ただし，多重継承には善し悪しがある。多重継承を使えば多様な処理を実現するシステムを開発しやすくなるが，一方で，システムの構造（クラス間の関係）が複雑になりやすいという危険性をはらんでいるからだ。 COBOL2002は従来のCOBOL規格（COBOL85）と互換性を保っている点にも注目してほしい。これは既存の膨大なプログラム資産を引き継ぐためである。最初にCOBOLの仕様書が発行されたのは1960年。その後もCOBOLは進化を続け，現在は1985年に制定された第3次規格（COBOL85）が主流である。この間，「やがてCOBOLは絶滅する」という声が何度も聞かれた。しかし現実はそうはならず，オープン系サーバーやメインフレーム上で現在もよくCOBOLは使われている。 これからオブジェクト指向を学ぼうとするCOBOLプログラマにとって，COBOL2002は入門しやすい言語である。いきなり言語仕様の全く違うJavaやC++を使うより，慣れたCOBOLでオブジェクト指向を勉強できる利点は大きい（図A[拡大表示]）。 だが，純粋にオブジェクト指向プログラミング言語として見た場合，既存言語との互換性はマイナスに働くおそれもある。オブジェクト指向の特徴を生かさなくても，従来のCOBOLの文法のままでシステムを開発できてしまうからだ。 むしろオブジェクト指向言語としての当面の用途は，システムそのものを開発するというよりは，他のオブジェクト指向言語で開発したシステムと，COBOLで開発したシステムとの連携部分の開発を受け持つことだろう。例えば，既存のCOBOLシステムを分散オブジェクト技術「CORBA」のオブジェクトとして利用させるプログラムを，COBOL2002を使って開発する，といった用途が考えられる。 高木 渉（たかぎ わたる）
|
