オブジェクト指向プログラミングの本質 - h

第４５回 IBM ユーザー・シンポジウム論文（小倉/北九州）
オブジェクト指向プログラミングの本質
ふじわら ひでひさ
藤原
秀久
［略 歴］
1989 年 日本電気株式会社入社
1997 年 三井海上システム開発株式会社入社
（現、三井住友海上システムズ株式会社）
現在
代理店支援グループ マネージャー
システム経験年数 18 年
原稿量
本文
10,340 字
要約
1,026 字
図表
9枚
1
第４５回ＩＢＭユーザー・シンポジウム論文
＜要
約＞
オブジェクト指向という概念がシステム開発の世界に取り込まれて久しいが、その理解を進めるこ
とは相変わらず難しいままである。特に、基本要素と言われる用語が、どのような意義を以ってオ
ブジェクト指向と関連しているのかわからないままでいる点は問題である。また、無分別に用語を
振り回し、「これがオブジェクト指向である」と説明されることが多く、学ぶ者の混乱の原因にな
っている。
C++や Java の文法を学びプログラムを作ることは容易である。決まりごとに従えば良いのである。
実務上は何の不自由も感じないが、果たしてそれで満足していて良いのだだろうか。業務プログラ
ムに適切な言語であるのか、オブジェクト指向プログラミングに見合った設計ができるのか、など、
これらの心配事は言語先行で文化が根付いてしまったことに端を発している。まずは、オブジェク
ト指向の出自を明らかにして、オブジェクト指向との付き合い方を冷静に見極めるべきである。
ひとつの源流は、アラン・ケイが大成した「メッセージ＋行動」という概念。これは、パーソナル・
コンピュータの開発が発想の原点であり、その世界においては「オブジェクト－対象」が具体的で
わかりやすい。一方、事務処理システムを構築する場合、概念的な世界が多く、「オブジェクト」
が掴みにくい。
もうひとつの源流は、ビアルネ・ストラウストラップが提唱した、「カプセル化、インヘリタンス、
ポリモーフィズム」である。プログラム言語の開発に取り込んでおり、実務的なアプローチである。
しかし、そのエッセンスを考察すると、
「抽象データ型」と「差分プログラミング」に行き着く。
オブジェクト指向プログラミングに携わる人は、「抽象データ型」と「差分プログラミング」が効
果的に機能するかを考えればよい。そうでなければ、従来の手続き型プログラミングで良いはずで
ある。手続き型プログラミングも数学的裏づけがあり、むやみに排他的な扱いをするべきではない。
学ぶものの迷惑は、本質の探究を怠った書物・雑誌があまりにも多いことである。一方で、自らも
ここまで見極めて欲しいものである。
２つの源流は、全く出自が異なり、その融合がなされていない。同じ場面で使うべきではない。「メ
ッセージ＋行動」という概念は設計時に、
「抽象データ型」と「差分プログラミング」は製造時に、
というように明確に分けて意識すればよい。２つの源流が融合されていないことについては、今後
の研究・アイデアに期待するところである。
2
第４５回 IBM ユーザー・シンポジウム論文（小倉/北九州）
目 次
1.
はじめに .......................................................................................................................................4
2.
基本的な用語の整理.....................................................................................................................4
2.1.
オブジェクト、オブジェクト指向 .......................................................................................4
2.2.
オブジェクト指向プログラミング言語 ................................................................................4
2.3.
プログラミング言語の分類 ..................................................................................................5
3.
本論文のアプローチ.....................................................................................................................5
4.
歴史を顧みる（その１） .............................................................................................................5
パロ・アルト研究所、アラン・ケイ ....................................................................................5
4.1.
4.1.1.
パロ・アルト研究所 ..................................................................................................5
4.1.2.
アラン・ケイ（Alan C. Kay） ..................................................................................6
4.1.3.
「データ＋手続き型」と「メッセージ＋行動型」 ...................................................7
5.
歴史を顧みる（その２） .............................................................................................................8
ダイナブック構想、Smalltalk、Alto ..................................................................................8
5.1.
5.1.1.
ダイナブック構想 ......................................................................................................8
5.1.2.
Smalltalk（スモールトーク） ..................................................................................9
5.1.3.
Alto（アルト）..........................................................................................................9
5.1.4.
オブジェクト指向観を築くもの ................................................................................9
6.
実装上のアイデア ......................................................................................................................10
6.1.
抽象データ型（Abstract Data Type） ..............................................................................10
6.2.
カプセル化 .......................................................................................................................... 11
6.3.
情報隠蔽（information hiding） ..................................................................................... 11
6.4.
メッセージパッシング........................................................................................................12
6.5.
メッセージパッシングとコール（Call） ..........................................................................12
6.6.
インヘリタンス（継承、inheritance） ............................................................................13
6.7.
ポリモーフィズム（多態性、polymorphism） ...................................................................13
6.8.
実装上のアイデアの本質 ....................................................................................................13
7.
事務処理システムとオブジェクト指向 .....................................................................................13
7.1.
事務処理システムへの適用判断 .........................................................................................13
7.2.
設計とプログラミング........................................................................................................14
7.3.
手続き型プログラミングが否定されること .......................................................................14
7.4.
事務処理用プログラミングに要請すること .......................................................................14
8.
最後に ........................................................................................................................................15
3
第４５回ＩＢＭユーザー・シンポジウム論文
1. はじめに
「オブジェクト指向について説明しなさい」と言われ、何を話して良いかわかる人は稀である。
それは、自分自身が納得していないのに自ら探求していないこと、良い書籍がないことなどが
原因と言える。ここでは“正しく知る”ことを目的に、オブジェクト指向プログラミングの原
点、その要素と言われるカプセル化、インヘリタンス、ポリモーフィズムなどについてオブジ
ェクト指向プログラミングとの関連を考察しながら、何を学ぶべきかのヒントを与えることに
する。
2. 基本的な用語の整理
2.1. オブジェクト、オブジェクト指向
最初に、用語の整理をしておく。
［１］
（１） オブジェクト
object ━━ n． 物体、もの、実物、対象（of、 for）；目的（物）
【コンピュータ】オブジェクト、独自のデータと処理手続きをもつソフトウェアの単位
【哲】客観、 対象
【文法】目的語； 哀れな［おかしな，ばかげた］人［物］
オブジェクト指向の“オブジェクト”を「もの」と訳すのは誤りである。
「対象」
「目的」
が正しい。英語の授業で S＋V＋O などの文法を学んだことを思い出すと良い。この"O"
は「目的語」である。Java の入門書、雑誌記事には、自動車や家を例にすることが多い。
また、露骨に「もの」と説明する記事もあり、活字がミスリード（miss lead）している
感がある。こういった例示はオブジェクト指向分析には適しているが、「もの」を想起さ
せるため本質を外しかねない説明である。
（２）オブジェクト指向
腰の据わらない響きのする単語である。「オブジェクト指向」の後ろに単語を付けないと
主体がわからないからだ。ここでは明確に、「オブジェクト指向プログラミング」とする。
その他にも、「オブジェクト指向分析」、「オブジェクト指向設計」という領域もあるが今
回は対象外とする。
2.2. オブジェクト指向プログラミング言語
結論のひとつを掲げる。プログラミング言語 Java で学べるのはその機能だけである。Java
でオブジェクト指向プログラミングを習得することは困難である。それは、Java が不完全
なオブジェクト指向プログラミング言語であることによる。研修や実践を通じて、
「どこがオ
ブジェクト指向なのだろう」
、
「ブジェクト指向プログラミングが身についたのだろうか」と
4
第４５回ＩＢＭユーザー・シンポジウム論文
腑に落ちないことが多いと思うが、もっともなことである。
2.3. プログラミング言語の分類
ここでプログラミング言語を２つに分類する。ひとつは、演算を中心に記述させる言語、も
うひとつはオブジェクト（対象）を中心に記述させる言語。
①演算を中心に記述させる言語
COBOL、C
②オブジェクトを中心に記述させる言語
Smalltalk、Squeak
など
演算とは、足したり掛けたり、文字列を編集したり、一連のデータ加工を指している。一般
的には手続き型と言われる。一方のオブジェクトを中心に記述させる言語では、オブジェク
トにメッセージを送る記述だけで構成できる。ところで Java はどちらに入るのだろう。Java
は二つの中間に位置する。
それは、
オブジェクトの動作の記述が演算中心であるからである。
3. 本論文のアプローチ
本論文では、つぎの３節を軸に述べ、それから導かれることをまとめることにする。
（１） アイデアの発生・発展の歴史を顧みる
（２） 概念を把握する
（３） 実装上のアイデアを整理する
（２）
（３）は用語の整理が中心となり、下記のような流れを導く。
表１．用語の整理の流れ
概念
実務上の
アイデア
「メッセージ」
、
「行動」
「抽象データ型」→「カプセル化」
「差分プログラミング」→「インヘリタンス」→「ポリモーフィズム」
4. 歴史を顧みる（その１）
「オブジェクト指向プログラミング」はいつ誕生したのか、その周辺を探る。そこには当時、何を
「オブジェクト－目的、対象」としたかが隠されているはずである。
4.1. パロ・アルト研究所、アラン・ケイ
4.1.1. パロ・アルト研究所
振り返る歴史はゼロックス社パロ・アルト研究所（PARC；Palo Alto Research Center）
にある。
2002 年に独立し現在は一企業である
（Palo Alto Research Center Incorporated）
。
5
第４５回ＩＢＭユーザー・シンポジウム論文
パロ・アルトはサンノゼ（San Jose）の近くにあり、ともにカリフォルニア州シリコンバ
レーの有名都市である。この PARC で現在にもつながるコンピュータ、ネットワークの基
礎研究が行われた。また、この後触れるアラン・ケイ、アドビーシステム社（Adobe Systems
Incorporated）を設立した人、マイクロソフト社（Microsoft Corporation）に移籍し
Multiplan（今の Excel）を開発した人など錚々たる人材を輩出している。PARC ではアラ
ン・ケイのダイナブック構想をもとに、1971 年プログラミング言語 Smalltalk、1973 年に
コンピュータ Alto が開発される。
4.1.2. アラン・ケイ（Alan C. Kay）
1940 生まれのコンピュータ科学者。PARC の研究員の時代に、パーソナル・コンピュータ
の概念を提唱し、グラフィカル・ユーザインタフェース、オブジェクト指向プログラミン
グ言語などを研究。オブジェクト指向プログラミング言語 Smalltalk を開発。チューリン
グ賞、京都賞を受賞。コンピュータ業界で知らない人はいないというほどの大御所である。
アタリ社（Atari,Inc.）
、ウォルト・ディスニー社（Walt Disney Company）を経て、ビュ
ーポインツ・リサーチ・インスティチュート（Viewpoints Research Institute）を設立し
ている。
ここでアラン・ケイ氏の投稿論文を紹介する。［２］
「現在使われているプログラム言語の大部分は、1950 年代に生まれたハードウ
ェアを前提として（中略） つくられたものである。このような考え方に基づく
言語では、厳密に逐次的にその記述をたどらなければならない。（中略） シス
テムが複雑になるにしたがって、さらに精密に手続きを組みあわせることが要
求されるようになり、幾何級数的に困難が増大していくことになる。
」
「こうしたものよりは見込みのあるデータアプローチとしては、はるかに大き
な汎用性をもつ構成素材をつくりだす、という道が考えられる。データと手続
きは、ともに行動適切なメッセージを受け取ると、なんらかの行為をする。そ
れ自体がコンピュータのような存在という単一の概念で置き換えることができ
る。
」
ここに重要な概念が提唱されている。オブジェクト指向プログラミング言語である。
「デー
タ＋手続き型」から「メッセージ＋行動型」への転換に大きな期待を持っていることがわ
かる。さらに、データと手続きを表舞台から降ろしたことは、カプセル化の提唱とも言え
る。
6
第４５回ＩＢＭユーザー・シンポジウム論文
オブジェクト指向プログラミング言語は、メッセージと行動のみで構成される。逆にメッ
セージと行動のみで構成されたプログラミング言語を、オブジェクト指向プログラミング
言語という。同論文の引用を続ける。
「それぞれの行動は同類のファミリーに属し（中略）。既存のファミリーから受
け継いだ性質ないしは、特徴をつなげ、拡張することによって、新しいファミ
リーを作成することができる。
」
これは差分プログラミングの提唱である。文意からわかるように、差分プログラミングは
行動に持たせるひとつのアイデアであり、「メッセージ＋行動型」プログラミングの本質で
はない。
4.1.3. 「データ＋手続き型」と「メッセージ＋行動型」
アラン・ケイ氏の論文に出てきた「データ＋手続き型」と「メッセージ＋行動型」を明瞭
に区別することはオブジェクト指向プログラミングを理解するうえで最も重要である。
Squeak というオブジェクト指向プログラミング言語を使い、メッセージ＋行動型の具体
例を見ていく。
〔式１〕1 + 2
COBOL、C、Java の解釈
1 に 2 を加える演算
Squeak の解釈
1 に+を送信する（パラメータが 2）
図１．簡単な式
COBOL や C、Java では、1 に 2 を加える演算を実行する。Squeak では、オブジェクト
“1”にメッセージ“+”を送信する、そのパラメータが“2”
。
〔式２〕 ( a + b ) ifTrue : [ expression ]
→ True/False ifTrue : [ expression ]
Squeak の解釈 True/False に ifTrue を送信する
（パラメータが expression）
図２．Squeak の判断文
a と b が等しければ expression を実行するという式。( a +b )は、値によって True また
は False になる。True も False もオブジェクトである。このオブジェクトにメッセージ
7
第４５回ＩＢＭユーザー・シンポジウム論文
ifTrue を送信する。送信時のパラメータが expression 。
これが C や Java の場合、式は似ていても解釈が違い、オブジェクトもメッセージ送信も
ない。論理演算し中括弧内の式を逐次実行、演算する。まさに手続き型である。
〔式３〕if ( a +b ) { xxxxx }
図３．C や Java の判断文
5. 歴史を顧みる（その２）
5.1. ダイナブック構想、Smalltalk、Alto
5.1.1. ダイナブック構想
アラン・ケイはプログラミング論理を目的に研究を重ねたわけではない。目的はダイナブ
ックの実現である。ダイナブックは国内ではすでに登録商標になっているが、アラン・ケ
イの夢、ダイナブック構想に共感した命名だと思われる。
ダイナブックとは全ての創造的思考のための理想のメディアである。絵を描く、作曲する、
演奏する。それも子供から大人までノートのように誰もが携帯できる。ハードウェアとソ
フトウェアが揃って初めて実現するが、まだ、完成に至っていないと見ている。ハードウ
ェアは Alto というコンピュータが第一号で暫定ダイナブックと呼ばれていた。ソフトウェ
アは Smalltalk で研究が重ねられた。ところで、ハードウェアは理想とするイメージにか
なり近い、あるいは越えているのではないだろうか。モックアップと、タブレット PC の
写真を比較すれば、その完成度はわかる。
近年のタブレット PC 発売によって、かなり理想に
近づいてきた。入力デバイスがペンであることは、
アラン・ケイの想定を超えているはずだ。ソフトウ
ェアには五線譜におたまじゃくしを描いて作曲でき
るものもある。写真中のソフトウェアは、筆跡を筆
で描いたように変換してくれるもの。ちなみに「王
羲之」風に変換してみた。
図４．タブレット PC
この節の最後に、アラン・ケイがイメージしたダイナブックのイラストを紹介する。子供
8
第４５回ＩＢＭユーザー・シンポジウム論文
たちが野原で自由に楽しそうに絵を描いているのか、作曲でもしているのか。オブジェク
ト指向はこのような豊かな感性から生まれていることも知っておくべきだろう。
5.1.2. Smalltalk（スモールトーク）
Smalltalk は純粋なオブジェクト指向言語であり、実行環境でもある。その説明は割愛す
るが、実験的に使ってもらい作られた作品アプリケーションを紹介する。電気回路図を作
成するアプリケーションで、驚くことに 15 才の少年の作品である。子供でも使えるという
Smalltalk の成熟度を示す良い事例である。現在 Smalltalk はシンコム・システムズ社
（Cincom Sytems）で販売している。
5.1.3. Alto（アルト）
Alto は Smalltalk が実装された パーソナル・コンピュータである。命名は Palo Alto から。
ビットマップ・ディスプレイ、マウスを備え、現在のパソコンの原型でもある。手に携える
には程遠いが、アラン・ケイの夢を乗せた「暫定版ダイナブック」である。
Alto はディジタル・イクイップメント社（現ヒューレット・パッカード社）の PDP のクロ
ーンマシンである。当時世界を席巻していたコンピュータは PDP である。研究員は研究所
に導入したがったが、経営陣がライバル会社の製品を購入してくれるはずがない。そこで自
ら作ってしまったのである。また、スティーブ・ジョブスが Alto に触発され製作したのが
Lisa であり、現在の Mac につながるのである。
5.1.4. オブジェクト指向観を築くもの
以上、原点に戻りアラン・ケイの視点を探ってきた。オブジェクト指向の原点は、「理想的
パーソナル・コンピュータ」にある。そこでは「対象―Object」がイメージしやすい。デ
ィスプレイ、入力デバイス、描画図形、描画座標。本来、オブジェクト指向云々は、パー
ソナル・コンピュータの世界のものである。一方、私たちが扱っている事務処理システム
の世界では具体的な対象物が意外と少ない「概念の世界」である。何をオブジェクトにす
べきか、どの粒度にすべきかの判断が困難であることは当然である。入門書の例はアラン・
ケイの提唱したオブジェクト指向の系譜であり、業務的な示唆はないことも自然なことで
ある。本のページをめくるように設計や開発が進まないことを当然のことと覚悟し、試行
錯誤を重ねることこそ重要な取り組み姿勢と考える。
9
第４５回ＩＢＭユーザー・シンポジウム論文
6. 実装上のアイデア
カプセル化、インヘリタンス、ポリモーフィズム。これらは雑誌・書籍ではオブジェクト指向
言語の必須要素といわれている。これは C＋＋を開発したビアルネ・ストラウストラップ
（Bjarne Stroustrup）が 1986 年に提案した概念である。C 言語の仕様を背景に、実務的な定
義を施している。簡単にまとめたものが下表。
表２．基本要素の整理
基本要素
カプセル化、インヘリタンス、ポリモーフィズム
メッセージ、行動
発生
C＋＋の論理的裏づけ
アラン・ケイなどの発想
レベル
実務的
メタレベル
開発言語に閉じたオブジェクト指向プログラミングを理解するのであれば、これで十分である
が、設計・分析 への第一歩とするならば、「メッセージ＋行動型」を基本要素と捉えたオブジ
ェクト指向プログラミングを理解すべきである。このようにふたつの源流があるのだが、後者
をオブジェクト指向プログラミングの本質的基本要素として捉える。以降の論述で、「カプセ
ル化、インヘリタンス、ポリモーフィズム」はオブジェクト指向言語とは本質的に関係無いこ
とがわかる。混乱しがちな用語であるため、ひとつひとつをよく吟味し、本質を解いていく。
6.1. 抽象データ型（Abstract Data Type）
ここで以降の論述のために「抽象データ型」についてまとめておく。抽象データ型はホーア氏
（※）がプログラム検証の研究の中で論述したものである。厳密に数学的な論文（Proof of
Correctness of Data Representations Acta Informatica） である。
（※）トニー・ホーア卿；計算機科学者、 プログラムの正当性の証明を形式化した
ことで有名。また、イギリスの誇る並列プログラミング言語 Occam（オッカ
ム）に影響を与えた。
参考になる説明を紹介する。
［３］
（中略）モジュール化言語においては、データとそれに対する操作は別ものである
ため、ある特定のデータに関して考えてみると、そのプログラムで用いられるすべ
ての手続きがそのデータを操作しうる可能性をもっているわけであり、誤操作の可
能性は常につきまといます。
（中略）具体的なデータに対して具体的な演算を行うものではなく、単にデータの
型とそれに対する操作を表現しているものと考えます。当然、モジュール内のデー
タに対する操作の定義は、モジュールの中に置かれます。モジュール内のデータ型
の定義の中に操作の定義も組み込んで一体化してしまうのです。
10
第４５回ＩＢＭユーザー・シンポジウム論文
実際の理解は C と C++比較するのがわかりやすい。C の構造体はデータを集めたもの。C++
はそれに関数を混ぜることができる。
struct student {
public {
int math;
//数学の得点
int english;
//英語の得点
int average()
//平均点を求める関数
}
}
図５．C++による抽象データ型
抽象データ型とカプセル化を同義とする説明もあるが、
情報隠蔽：
抽象データ型に求める性質
カプセル化：
情報隠蔽を実現するための方法
と考えたほうが的を射ている。
6.2. カプセル化
「抽象データ型に要請した、データと操作は保護されるという性質」と定義できる。具体的
には次の２点を指しているが、この性質は従来から存在する。
①クラス名を修飾しないと利用できない。
②使用クラスを明示しないと利用できない（Java では import）
。
C 言語の構造体は、構造体変数を修飾しないとメンバーにアクセスできない。COBOL も OF
修飾する点で同様である。また、Java の import は、他言語のリンク編集でライブラリを指
定することに類する。このように、
「カプセル化」は抽象データ型が当然持ち合わすべき性質
であり、新しい概念とは言いがたい。
6.3. 情報隠蔽（information hiding）
情報隠蔽はカプセル化と同じ概念として捉える向きもあるが異なる概念。「モジュール内部
の変数を自由に参照させない」という説明が多いが、これだけでは理解不能である。COBOL
では他のモジュールから変数を参照することはできない。C 言語では関数の外で宣言された
変数（外部変数） だけが他のモジュールで extern を指定して参照できる。Visual Basic で
はプロシージャの外で宣言された変数がプロシージャ共通の変数（モジュール変数）となる。
11
第４５回ＩＢＭユーザー・シンポジウム論文
このようにモジュール間で変数を共有するためには強い制約がある。他モジュールから変数
を参照することは多くない。アセンブリ言語の時代とは違うのである。また、UNIX ではプ
ロセス内共有メモリ（malloc）、プロセス間共有メモリ（shmget）を使うことができるが、
これらを指しているとも考えにくい。そのほか、
「振る舞いが見えないようにすること」とい
う説明も目にするが、高級言語では至極当然のことである。
各言語ともに勝手に変数を参照できない仕様になっている。これを敢えて「情報隠蔽」と称
し、オブジェクト指向プログラミング言語の仕様であると取り上げる価値は小さいのではな
いか。
Java では public なクラス変数が、別クラスから参照できる。公開不要な変数は private に
する。情報隠蔽の考え方を Java で説明するとすれば、
「オブジェクトを作成するとき、むや
みにクラス変数を公開せず、必要なものだけ公開すべき」ということになろう。言語仕様の
観点では、
「クラス変数は public だけでなく private も備えよ」ということになる。
以上から、情報隠蔽は直接オブジェクト指向プログラミングには関係ないことが理解できる。
基本要素の仲間入りしてしまった経緯はつぎのように推測する。
抽象データ型 → カプセル化 ―＜概念の混同＞→ 情報隠蔽
図６．情報隠蔽と抽象データ型の関係
6.4. メッセージパッシング
メッセージパッシングは、抽象データ型が新たな概念としてデータと操作をひとつの集合（こ
こでは便宜的にクラスと称する）としたことに端を発すると考えられる。データを参照・更新
する場合、操作する場合は、必ずクラスが仲介役となる。実装上はクラス名を修飾することで
ある。そのため、
「クラスに依頼する」という考え方が必要になったと言える。このようにメ
ッセージパッシングの概念も、抽象データ型の存在なしでは発生し得ない。
6.5. メッセージパッシングとコール（Call）
メッセージをオブジェクトに送信することをメッセージパッシングと言う。言語実装ではコ
ール形式と見た目が変わらないものもあるが、概念はまったく異なる。メッセージパッシン
グでは、
メッセージの送信元オブジェクトと送信先オブジェクトは対等な関係にある。一方、
コール方式では呼び出す側（caller）が親、呼び出される側（callee）が子というように親子
関係が存在する。参考にいくつかのメッセージパッシングの形式を紹介しておく。
12
第４５回ＩＢＭユーザー・シンポジウム論文
Smalltalk
recievingObject whatToDo : 引数
Objective-C
[ recievingObject whatToDo : 引数 ]
C++
recievingObject whatToDo(引数);
Flavor
send recievingObject whatToDo (引数);
図７．メッセージパッシングの形式
6.6. インヘリタンス（継承、inheritance）
インヘリタンスは素直に“差分プログラミング”と捉えるべきであろう。プログラムの共通部
分に、必要に応じてプログラムを追加するイメージである。概念は容易に把握できるのでこれ
以上説明はしない。強いてコメントしておくべきことは、プログラムの共通部分と汎用的なモ
ジュールとは、異なる概念であること。ところで、事務処理を機械化するプログラムでどれだ
け“継承”の恩恵にあずかるかは疑問である。どちらかと言えば、制御部分に多く登場するも
のかもしれない。
6.7. ポリモーフィズム（多態性、polymorphism）
インヘリタンスの性質を活用した考え方である。複数の下位のデータ型が、それぞれ同じ名称
で異なる動作を定義すると実現できる。「パラメータの型によって異なる動作が定義できる」
ことを指す場合が多いが、これは言語仕様としてのポリモーフィズムである。説明するときも、
学ぶときも明確に区分する必要がある。
6.8. 実装上のアイデアの本質
以上６章での結論として、
「抽象データ型」と「差分プログラミング」
が実装上のアイデアの本質と把握すればよいことがわかる。
7. 事務処理システムとオブジェクト指向
7.1. 事務処理システムへの適用判断
最も悩ましいのは、事務処理システムにオブジェクト指向の概念が適用できるか否かである。
オブジェクト指向プログラミングが、従来の手続き型プログラミングのパラダイムシフトだ
とすると、論理的には全ての業務システムに適用できることになる。しかし、経験的に全て
が正しいとは言えないのが事実である。
たとえば「１００万件のデータを集計し合計を算出するバッチ処理」
。データ型、合計ロジッ
クを抽象データ型としなければいけないのであろうか。論点はその効果である。
13
第４５回ＩＢＭユーザー・シンポジウム論文
①抽象データ型にすると、データと操作がひとまとまりになり、整理されて良い。
②差分プログラミングが生かされ、効率的なプログラムを作成することができる。
２点のいずれかが適用できるものであれば、オブジェクト指向プログラミングが効果を発揮
しそうである。
「しなければならない」という風潮に流され、本質を見失わないことが肝要で
ある。
7.2. 設計とプログラミング
オブジェクト指向の概念から「メッセージ＋行動」が生まれ、実装上のアイデアから「抽象デ
ータ型」、｢差分プログラミング｣が生まれた。この出自の異なる両者は、生まれたままで、ま
だ融合されていない。この状況で、両者を混在させて説明することは避けるべきと考える。ま
た、オブジェクト指向設計は、どうやら、「メッセージ＋行動」を基礎に標準化(UML)が図ら
れている。設計はできても、素直にプログラミングに落とし込むことができないのは、考え方
の違うものを扱っているからである。設計は「メッセージ＋行動」、プログラミングは「抽象
データ型」
、｢差分プログラミング｣と割り切って教えるべきではないだろうか。
7.3. 手続き型プログラミングが否定されること
「手続き型プログラミングは人間の思考をコンピュータに合わせているため良くないものだ」
というのが一般的な論調である。手続き型プログラミングは、言い換えれば、算術であり、数
学そのものである。そのことは、チューリングによって提唱・証明された、チューリングマシ
ン、チューリングの定立で十分であろう。「プログラムに数学を持ち込むな」という乱暴な意
見は聞いたことはない。オブジェクト指向への過度な信奉がこの論調を作っていったものと理
解したい。数学的な、つまり、手続きが似合うのであれば、素直に手続き型プログラミングを
使えばよいだけのことである。
7.4. 事務処理用プログラミングに要請すること
「オブジェクト指向は大きなパラダイムシフトである」という言葉の陰になっていることが、
事務処理システムのためのプログラミング言語である。下記は一例である。
①文字列の比較は"＝"（イコール）で実装すべき
②明示した桁数の型を実装すべき
③固定小数点を実装すべき
ほとんどのプログラム言語は、学問・研究分野で開発されているが、実務分野である事務処
理システムにも光を当てていくべきと考える。
14
第４５回ＩＢＭユーザー・シンポジウム論文
8. 最後に
「Java はオブジェクト指向プログラミング言語だ」、「Java でオブジェクト指向プログラミ
ング言語を習得しよう」と思っていても、実際には、「データ＋手続き型」のプログラミング
が大半を占めていないか。当然である。Java は少し「メッセージ＋行動型」の文法があり、
残りは「データ＋手続き型」であるからだ。Java の参考書の最初には何が書かれているか。
変数型、演算子、制御文である。これは、「データ＋手続き型」のプログラミング言語と何も
変わらない。
「ここまで読んできて私は何をすれば良いのか」と思う人は多いであろう。まず、製造に携わ
る人へ。Java は Java。その機能を十分理解し製造にあたればよい。
「オブジェクト指向とは
何かも語れずに Java を扱うとは何事か」という人は、大抵、何も語れない人である。「Java の
持つ性質 オブジェクト指向 を十分生かしているのか」より「Java の持つ機能を十分生かす
こと」が大事である。冒頭にも説明したが、Java は純粋に Object Oriented な言語ではない。
さらに、C++から Java に引き継がれている情報隠蔽、継承、多態性は「クラス指向」とでも
いうべき概念であり、オブジェクト指向の基本要素とは言いがたい。つぎに設計に携わる人へ。
「メッセージ＋行動型」だけがオブジェクト指向であると捉えて設計して欲しい。
何れにしても記事に書かれていることを鵜呑みにしているようでは、理解・修得できない世界
である。自分で調べ考えることこそシステム・エンジニアに求められる姿であるはずだ。
参考文献
［１］goo 辞書（http://dictionary.goo.ne.jp）
［２］鶴岡雄二、
「アラン・ケイ」
、出版社名：株式会社アスキー、発行年：1992 年 3 月 31 日
［３］春木良且、
「オブジェクト指向への招待」、出版社名：啓学出版、発行年：1989 年 7 月 25 日
15