InfoQ

InfoQ

News

マイブックマーク

ブックマークするためにログイン または 会員登録 する

ブックマークされました!

ブックマークがエラーになりました。もう一度お願いします。

オブジェクト指向プログラミングは間違いだったか?

作者 Dave West , 翻訳者 大田 緑 - (株)チェンジビジョン 投稿日 2010年7月28日

セクション
デベロップメント,
エンタープライズ・アーキテクチャ,
設計/アーキテクチャ
トピック
Object Oriented Design ,
メッセージング ,
プログラミング ,
Architecture
タグ
Functional Programming ,
OOP ,
SmallTalk ,
Erlang

原文(投稿日:2010/07/12)へのリンク

「メッセージ送信を行うSmalltalk-80から生まれたオブジェクト指向を振り返って、継承などの現在の状況を見てみれば、私たちは間違った道を下ってきたと言えるだろうか?」 これは、QCon London 2010 インタビュー の最初の質問だった。このインタビューを受けたのは、Erlangの最初の開発者であるJoe Armstrong博士とSmalltalk、OOP、パターンに長い間関係しているRalph Johnson博士だ。私たちは「間違った道」を当てもなくさまよってきたが、これはオブジェクトの考え方の実現方法に欠点があったためであり、この考え方自体の欠点ではないと2人は述べた。実際に、Ralph Johnson博士は以下の点から始めた。

あるアイデアを思いついて世の中に出すと、たいていの人にとって急進的過ぎるのはよくあることです。大半の人はすべてのことを取り入れずに、一部だけ手に取ります。そして、あなたが手にするのはこの不完全なものなのです。

オブジェクト指向言語の見本として多くの人たちが支持したSmalltalkでさえ、オブジェクトの典型に似たようなものとして考えられた。Johnson博士はSmalltalkに関するある2つのことを提案した。

... Smalltalkは基本的な間違いを犯したと思います。Smalltalkは、Smalltalkプログラマではない人たちには評価できないことがあります。それは、Smalltalkでプログラミングしている場合、そして、Smalltalkでデバッグしている場合、システム全体をデバックしていることです。

続けて

なぜなら、Smalltalkではイメージの中にすべてのことがあります。古いものと新しいもののバージョンは追跡し続けられません。また、複雑さという問題もあります。システムを構築すると、少数の人たちができることには制限があって、そこではSmalltalkはそれほどよく機能しません。

この言語のもっとも熱心なファンにとっても、アプリケーションクラス、開発とデバッグ用ツール、ライブラリなどすべてが「イメージ」の中にあるという事実は、常にSmalltalkの問題であった。しかしながら、これは、Cargill Lynx Projectのような非常に大きくて重要なシステムを人々が構築するのを止めはしなかった。Lynxは、地球規模の穀物取引システムであり、アメリカ合衆国の150サイトの1,500以上のユーザをサポートし、ここ10年以上製作されている。その間、Lynxは100人以上のプログラマをうまく巻き込み、完全なバージョンコントロールと強固なテストとデバッグの機能を持ち続けてきた。Lynx Projectのような成功した大規模システムが、Ralph Johnson博士の懸念を鎮めたり、Smalltalkがオブジェクトの考え方に関して欠点のある実装だったという前提に異議を唱えたりするものではない。単に見解を付け加えただけだ。

どのような特徴がこの言語をオブジェクト指向にしたかという質問は、1990年代に広範囲に渡り、感情的に議論された。QCon Londonのインタビューにおいて、Joe Armstrong博士の論文のアドバイザが、まさに同様の議論をしたことを引用している。

私は、オブジェクト指向プログラミングというものに疑問を持ち始めました。Erlangはオブジェクト指向ではなく、関数型プログラミング言語だと考えました。そして、私の論文の指導教官が言いました。「だが、あなたは間違っている。Erlangはきわめてオブジェクト指向です。」 彼は、オブジェクト指向言語はオブジェクト指向ではないといいました。これを信じるかどうかは確かではありませんでしたが、Erlangは唯一のオブジェクト指向言語かもしれないと思いました。オブジェクト指向プログラミングの3つの主義は、メッセージ送信に基づいて、オブジェクト間で分離し、ポリモーフィズムを持つものです。

Armstrong博士は、アドバイザの議論によって完全に納得させられたのではないと述べたが、Erlangは「唯一のオブジェクト指向言語かもしれない」と考えているようだ。引用文で挙げられた3つの特徴の他に、単一継承と動的型付けはオブジェクト指向言語であるために「絶対に必要なもの」としてしばしば引用された。

インタビューの中で、Johnson博士とArmstrong博士は、オブジェクトの考え方は重要だったし、今も重要だと提案している。Armstrong博士は、Erlangがどのようにオブジェクトの考え方とオブジェクト指向言語の特徴を実装しようとしたかを指摘するのに時間を費やす。Johnson博士は、特にSmalltalkでオブジェクトの考え方を実装しようとした以前の試みを批評するのにさらに時間を費やしている。ここで、Smalltalkとオブジェクト (Johnson博士が共著者のデザインパターンの本は、タイトルにオブジェクト指向という言葉を含む) を長い間支持するRalph Johnson博士がひとりではないことは奇妙に思えるかもしれない。

Dave Thomas氏は、オブジェクトとSmalltalkに密接に関連するもう1人の人だ。Thomas氏のチームは、Digitalkの手法 (最初のWindows用Smalltalk) のための最初の「Goodies Pack」を作り、Thomas氏はIBMのVisualAge Smalltalkとなるものを作った会社の設立者でCEOだ。このチームは、とても人気があるプログラミングツールであるEclipse (もともとは、SmalltalkのためにSmalltalkで書かれていた) を開発した。「オブジェクトは間違いだった」「私は処理状態を把握している罪人だ」とThomas氏は言った。これらの言い方は劇的な効果があったが、一方でオブジェクトの考え方のSmalltalkの実装にある「間違い」を指摘するものであった。例えば、状態に注目していること、クラスとイメージベースの言語のなかで同時に起こるモデルがないこと、メッセージングに注目していないことなどである。

「オブジェクト指向」という言葉を最初に作ったAlan Kay博士とSmalltalkを作ったXerox PARCのDan Ingalls氏や他の人たちでさえ 批判的だ。Computerworld Australiaの最近のinterviewを紹介する。

Kay博士は以下のように述べた。

私がこの言葉を考え出しました。(これは悪い選択でした。メッセージ送信のもっと重要な考えを十分強調していません。) この考え方の一部はいくつかのシステムの中にありました。メッセージだけで伝達する効果的な仮想マシン全体をとことん突き詰めて考えれば、もっと包括的な基礎ができ、スケーリングを提供したでしょう。私のリサーチコミュニティであるARPA-IPTO (米国防総省の研究機関の情報処理技術オフィス)は大規模ネットワーキングを始め、ポリモーフィズムのようないくつかの強力な「代数」のプロパティを持ちました。これは、その仮想バージョンとなったでしょう。しかしながら、私はSmalltalkの大ファンではありません。今日のたいていのプログラミングシステムと比べるととても好ましいものですが。(私は、今日のプログラミングシステムはどれも好きではありません。今日の実際にあるプログラミングの問題にとって、システムにもエンドユーザにも、どれも適していないと思います。)

Smalltalkに対して湧きあがった最近の批判は、古いCoastersの歌、Charlie Brownの歌詞の中で繰り返し言われたことを思い出させる。(どうしてみんないつも僕をからかうの) Johnson博士、Armstrong博士、Kay博士、Thomas氏は、もちろん 「Smalltalkをからかっている」 のではない。QCon Londonのインタビューで言われたことや他の批判は、「たいていの人にとって急進的すぎる」(Johnson博士) 考え方をどのくらいプログラミング言語の中に実装できるのかという疑問だ。

オブジェクトの考え型がプログラミング言語の定義や構造に直接役に立たない可能性もある。Computerworld Australiaのインタビューで、Kay博士は以下のように指摘した。

私にとって、本当のオブジェクトのセマンティクスに関する素晴らしいことの1つは、本当のオブジェクトが「端から端まで本当のコンピュータ(RCATWD)」であることです。これによって、何でも表せる完全な能力をいつでも保持できます。古いやり方は、すぐにコンピュータではない2つのこと、データとプロシージャに行き着き、不意にふるまいに合わせて最適化と特定の決定を任せる能力を失っていました。言い換えれば、常に本当のオブジェクトを持つことにより、ほしいものを再現し、惑星の周りに送る能力を保持します。そして、RCATWDはまた、両方向を完璧に保護します。これはインターネットのハードウェアモデルの中に見られます。(使えるもので、唯一の本当のオブジェクト指向システムかもしれません) 無料で言語拡張機能を手に入れるには、メッセージ形式に従うだけです。私が70年代に考えたのは、パーソナルコンピューティングと同時に取り組んでいるインターネットは、本当に素晴らしいスケーラブルな設計であり、ハードウェアでキャッシュできる仮想マシンの仮想インターネットを作るべきだというものでした。これが実現されなかったのは本当に残念です。

もし「本当のオブジェクト」がRCATWDならば、各オブジェクトはその本質にもっともふさわしいプログラミング言語を使って実装できる。これは、「多言語プログラミング」という言葉に新しい意味を与えるだろう。

特集コンテンツ一覧

GAE開発の落とし穴

Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します

イベントレポート:「Coqチュートリアル#1」

去る1月12日、定理証明支援系ツールCoqの初心者向けチュートリアルが開催さ れた(http://kokucheese.com/event/index/23667/)。今後も2月2日 (http://kokucheese.com/event/index/23744/)、2月9日、2月16日と引き続き開 催されていく予定である。本記事では、開催の様子をレポートする。

Javaの未来についてのNeal Gafter氏とのディスカッション

Choosing Options

Neal Gafter氏はOracleによるJava買収の影響に関する議論、Javaにセグメンテッドスタックやメタオブジェクトプロトコルを追加することについての主張、そしてJavaとC#との比較について話をしてくれた。

Google Dartのエッセンス:アプリケーションの構築、スナップショット、Isolate

GoogleはVMをともなう新しい言語であり、JSコンパイラでもあるDartをプレビューした。 InfoQはDartのアプリの構築に貢献する文法の裏側を探った:スナップショット、Isolate、モジュール方式

CSPベースのモデル検査ツール「Process Analysis Toolkit」

本記事ではCSPベースの「マルチドメイン・モデル検査ツール」である、PAT(Process Analysis Toolkit)について紹介する。モデル検査は、形式手法(Formal Method)という方法論を基礎とする技術であり、複雑さが増大しながらも安全性を求められる、現在のソフトウェア開発の状況に対する処方箋の1つとして注目されている手法である。

Jenkinsによる継続的インテグレーションのススメ(4) ~CloudBeesでJenkinsをサービスとして使う~

前回まで、Jenkinsの幾つかの側面に注目して解説をしてきました。シリーズ最後の今回は、Jenkinsをサービスとして使う方法を紹介します。

書籍『抽象によるソフトウェア設計-Alloyではじめる形式手法-』の紹介

Alloyは、MITにて開発された仕様記述言語であり、ツールによる自動解析を使い、インクリメンタルに形式仕様が書けることが特長である。筆者らはAlloy開発者による、Alloyを使った形式手法入門書を翻訳、今夏にオーム社より刊行した。本記事では、Alloyの簡単な概要と、翻訳書『抽象によるソフトウェア設計』(「Alloy本」)を紹介する。

Windows デバイスで開発するタッチユーザーインターフェイス

スマートフォンを中心としたマルチデバイスにおけるタッチユーザーインターフェイスへの対応は、既に必須の項目となりつつある。本記事では、Windows デバイスにおける UX のベースとなっている「メトロ」というデザイン言語を掘り下げながら、既存環境を意識しつつもどのようにタッチユーザーインターフェイス開発に取り組んでいくべきであるかについて解説していく。