「C++プログラミング言語の歴史と特徴」連載第21回目の今回も前回に引き続き次の公開論文を精読していきます。

第1回連載資料論文
　筆者はかつて次のような記事を目にしました。一種の事例報告記事というものですが、16億円という膨大な経費をかけて作り上げたシステムを結局捨ててしまった！、という実際にあったお話です。興味のある方はぜひ目を通されるとよいでしょう。筆者は、当初信じられない思いがしましたが、"もしかすると、これに似た事例は多いのではないか"と不安になっています。

16億円の投資が無駄に！

　筆者はこの記事を一読後、"自分のことを自分の言葉で表現する"ことの重要性を改めて認識させられました。実体のない時代の流れや雰囲気に飲み込まれ、自分の言葉を失うことはとても危険なことです。筆者は今さらのようにそれを実感させられました。本連載を閲覧されている皆さんはご存知のように、C++の設計者であるStroustrup氏は、自分の言葉をこの上なく大切にします。同氏が公開する文章は思慮の果てに生み出された成果物であり、一文たりともないがしろにできません。現場を冷静に観察し、自分の言葉で考えれば、4500万円のシステム構築経費削減なども決して夢ではありません。

　Stroustrup氏は、自分の考えている内容を書籍や各種の論文として公開しています。そして、同氏は、1990年頃開始されたC++標準化委員会の会合にほぼ毎回出席されています。おそらく、Stroustrup氏は、多くの人からいろいろな意見をぶつけられていると思います。実際、1994年発行「The Design and Evolution of C++」や最近の論文に目を通してみると、同氏の元に多数の意見と提案が寄せられていることが分かります。しかし、それらの意見や提案のいくつかは、採用されることはなかったようです。Stroustrup氏は、提出者に対して、"なぜ採用しないか"を説明する義務がありますが、その義務も立派に果たしているようです。

　ところで皆さん、説明義務を十分に果たせない場合、どのようなことが起こると思いますか？常識的に考えれば、提出者は"ふざけるな！"と憤慨することになります。Stroustrup氏は、自分の言葉で不採用理由を説明していると思います。自分の言葉で語ることは、語る内容を理解していることですから、説明を受ける相手はその説明に矛盾がない限り、納得する以外にありません。さらにいえば、Stroustrup氏の説明内容から、自分の認識の甘さをはじめとする、多くのことを学ぶことができると思います。

　そろそろ本論に入ります。今回は、「4.3 Object-Oriented Programming」節の意味を考えます。この第4節のタイトルは通常、OOPと略記され、オプジェクト指向プログラミング、と邦訳されます。本記事では、資源消費を考慮し、OOPと総称します。

　OOPのOはオブジェクトを意味しますが、OOPの中心概念はクラスといわれます。開発経験年数に関係なく、ほとんどの開発者は、オブジェクトとクラスの違いを区別できません。できたとしても、その区別の根拠を自分の言葉で説明することは残念ながらできません。筆者は時折、1990年代初頭の月刊誌などを取り出し、オブジェクト指向関係記事を読むことがあります。そしてほぼ例外なく、"この力作には感謝するにしても、読まなければよかった！"、という結論を得ます。筆者はこれまでの経験から、オブジェクト指向を学ぶ上では、次の視点がきわめて有効ではないかと考えています。

・JavaとC#の基になったC++の歴史と設計思想を学ぶ
・そのためには、Bjarne Stroustrup氏の論文（発想）に触れる
・表現道具としてクラスを使ってみる

　Stroustrup氏は、もともとは分散コンピューティングの研究者でした。分散コンピューティングですから、複数のコンピュータがネットワークで接続されています。そして、ネットワークを構成するそれぞれのコンピュータは固有の役割を割り当てられています。この場合、複数のコンピュータはそれぞれクラスとして表現できます。必然的に複数のクラスが出来上がりますが、それらのクラスの性質をじっくり検討してみると、なんらかの共通性があることにだれでも気づきます。その共通性は独立した共通クラスとして整理され、上位概念として位置付けられます（汎化）。このようなクラスの生成過程を冷静に振り返ると、分散コンピューティング環境を構成する各コンピュータは、共通クラスの派生クラスであることが分かります（継承・特化）。

　たとえば、コンピュータという共通概念（クラス）があり、分散コンピューティング環境内のコンピュータAやコンピュータBなどの、個々の具体的なコンピュータ（オブジェクト）はその共通概念（スーパークラスや基本クラスと呼ばれる）から誕生しています。この例えは非常に単純ですが、クラスとクラス階層、汎化と特化、継承などのほぼすべてのオブジェクト指向概念を含んでいます。

　第4.3に目を通して見ると、次のような用語が使われています。

・User-defined type（UDT：自分の型を定義すること）
・Derive a class from another（クラス派生：自分のクラス階層を定義すること）
・virtual function（ポリモーフィズム：C++仮想関数の意味を理解し、それをうまく活用する技術能力を身に付けること）

　オブジェクト指向を論じる多くの専門図書は、これでもかこれでもか、と専門用語を乱発します。しかしStroustrup氏は、ご覧のように、3つの用語を紹介するにとどめています。筆者の個人的な見解を述べれば、ここに紹介されている3つの用語をきちんと理解しておけば、他の市販図書はすらすら読める、と思います（すらすら読めない図書は、問題を抱えていると考えてよいと思います）。この"読める"という意味の中には、"この図書の執筆者は自分の言葉で語っていない！"という判断も含まれます。悪い表現になりますが、市販図書の中には、結果的に読者の学習意欲をそいだり、著者本人の混乱をそのまま文章化しただけ、というものが結構あります。注意したいところです。

　プログラミング学習を始めて間もない方や、オブジェクト指向論をこれから学習しようと考えている人にとっては、第4.3節内で紹介されているソースコードの意味と醍醐味を理解できないと思います。筆者はここではソースコードの詳しい説明はいたしませんが、紹介されているソースコードは、オブジェクト指向を学ぶ上で大変貴重なものです。その上、大変分かりやすい、といってよいでしょう。お時間のあるときには、ソースコードを味わいながら、多少時間をかけて読んでみるとよいでしょう。ソースコードは暗記の対象ではなく、あくまでも作成者の表現内容であることを忘れないようにしましょう。"ソースコードを覚えよう！"と力んでしまうと、プログラミング言語はおろか、プログラミング自体の学習が苦痛になります。ソースコードは推理小説のようなもの、と考えるようにしましょう。たとえば、次のソースコードを見てください。

virtual int get_value() = 0;

　さて皆さん、このソースコードからどのようなことをお感じになりますか？暗記中心でプログラミング言語を学んできた人は、おそらく、"これは純粋仮想関数の定義です"、と答えるだけでしょう。筆者は違います。筆者なら次のように答えるでしょう。

　"これは確かに、純粋仮想関数の定義コードである。しかし、魅力的なのは、C++の発展の歴史を示していることである。"

　このソースコードは次のような歴史を教えてくれます。

　int get_value(); // C関数の踏襲
　virtual int get_value(); // virualキーワードの追加導入
　virtual int get_value() = 0; // 「=0」の追加導入

　ご覧のように、純粋仮想関数が誕生するまでの3段階の歴史を示しています。第1段階では、C言語の関数の影響を受けていることが紹介されています。次の第2段階では、C時代に確立した関数にvirtualキーワードを追加して仮想関数を定義できるようにしています。最後の第3段階では、仮想関数に「=0」を追加することにより、純粋仮想関数を定義できるようにしています。Stroustrup氏は、「=0」を"奇妙な表記"と形容することがあります。これはどういうことかといえば、純粋仮想関数のC++への導入の背景にはいろいろな複雑な事情があったということなのです。

　純粋仮想関数の導入は当初反対されたようです。その概念を理解できる人が少なかったともいわれます。Stroustrup氏は、純粋仮想関数の必要性をかなり精力的に説いて回ったと思われます。確かに、「=0」という表記は普通ではありませんね。皆さん、"「=0」という表記は普通ではない"ということの意味がお分かりですか？それは、私たちにとっては習得が難しい！、ということです。筆者はこのような場合、自分の言葉を大切にしている開発者が書いた、分かりやすいサンプルソースコードを探すことにしています。第4.3節に紹介されているソースコードは、文句なく分かりやすいサンプルコードです。

　以上のような視点からプログラミング言語を眺めると、ソースコードの検討は、プログラミング技術の学習であるとともに、プログラミング言語の歴史の学習、プログラミング言語による表現の学習、という意味を持っていることも分かると思います。

前へ | 次へ