
The Rational Edge
オブジェクト指向を超えて
page1|page2|page3
ワーチェスター工芸研究所業務学教授
Gary Pollice
2005/11/25
The Rational Edgeより:元ソフトウェア開発者のGary Pollice教授は、オブジェクト指向の概念を最初から学ぶコンピュータサイエンスの学生は、構造化プログラミングテクニックが染み込んだプログラマーより、これらをソフトウェア開発プロジェクトに応用するときに苦労しないと指摘する。本稿では構造化とオブジェクト指向の考えを考察し、オブジェクト・ファーストの教授法のメリットを解説して、アスペクト指向のプログラミング手法が普及する中でのアスペクト・ファースト・アプローチへの移行の可能性を考えてみたい。
筆者は、大学生のころ初めて携わったハイテク系の仕事の1つに関連し、ALGOLのサブセットを学習するクラスに1日参加しただけで4Kバイトのメモリを搭載したコンピュータをプログラムできた。筆者は、気象計算処理を実装するのに十分な文法を学んだのだ。いま思い出すと、マシンを制御して自分の命令に従わせるということは強烈な魅力だった。程なく筆者は、手当たり次第の教本を徹底的に調べ、ほかの言語も学習し始めた。しかし筆者は、優れたコードを書くにはコマンドシーケンスをまとめるだけでは足りないことにすぐに気付いた。人類は最近になって構造化プログラミングを発見し、筆者も、その手法だけでなく背景にある理論にも魅了された。一生をかけて熱中できる対象を見つけたのだ。
◆ 構造化プログラミングの紹介
筆者は、構造化されたプログラムは制御構造を連続して応用することにより作成できる、と考えるBohm-Jacopini理論を早い時期に学んだ。この分かりやすい理論はプログラマーに幅広い影響を与えた[注1]。そこから、われわれはプログラムを構築するための選択肢について考えるようになった。この考え方は、各種プログラミング言語へ次々に影響を与えていった。1970年代半ばになると、優秀な開発者たちは構造化されたプログラミング、分析、デザインを使って業務ソリューションの開発に取り組んでいた。
[注1] この理論は、Corrado BohmとGiuseppe Jacopiniの共著による1966年5月出版の「Flow Diagrams, Turing Machines, and Languages with Only Two Formation Rules」ACM Communications 9(5)にある。当初、これには順番と選択のわずか2種類の制御構造しかなかった。その後作業が進み、利便性実現のために反復(ループ)構造が追加された。
- - PR -
プログラミングの経験が多少あれば、構造化手法を学ぶのは簡単だった。自覚の有無は別にして、われわれは原理をすでに自分たちのものにしていたのだ。構造化プログラミングは、われわれの世界観と相性が良かったのだ。
しかし、1980年代前半にオブジェクト指向(OO)が登場すると、これが劇的な変化を生み出した。初のオブジェクト指向言語であるSimulaが1960年代には投入されていたが、その影響は長続きせず、大半のプログラマーが1980年代までその存在を知らなかった。本格的なOOブームの引き金になったのは、言語であり、環境でもあったSmalltalkだった。Smalltalkを開発した、あの有名なXerox Palo Alto Research Center(PARC)の研究者らは、驚くべきビジョンをこれに対して思い描いていた。1978年にアリゾナ州トゥーソンで開催されたFifth Symposium on Principles of Programming Languagesでは、Dan IngallsがSmalltalkの論文を発表した。その論文の導入部が同氏の描くビジョンをかなり明解に述べている。
Smalltalkプロジェクトの目的は、情報の世界であらゆる年齢層の子供を支援することだ。十分簡潔で強力なメタファーを特定して活用し、1人の人間が数字やテキスト、そして音や画像まで、さまざまな情報を利用し、創造的に扱えるようにすることが課題だ。われわれの経験では、Simulaのクラスとインスタンスの概念は、情報構造の傑出したメタファーだ。同じように、処理の記述にはメッセージ送信のコンセプトも簡潔かつ一般的であることが分かった。われわれは、この機構を既存システムの「仕様」として提供するのではなく、これら2つのメタファーをSmalltalkプログラミング言語の出発点とすることにした。その結果、パーソナルコンピュータでテキスト編集、デバッグ機能、ファイル処理、グラフィックス表示を独自に実現する動きの軽快なインタラクティブシステムが完成した[注2]。
[注2] 論文の完全版は、http://users.ipa.net/~dwighth/smalltalk/St76/Smalltalk76ProgrammingSystem.html
Ingallsは次に、「Smalltalk言語は、関数ではなくオブジェクトが中心になっており、コンピュータサイエンスの経験のある人は、そこで混乱する場合が多い」と続けている。だが、これは控えめな表現だった。COBOL、FORTRAN、Pascalといった手続き型言語を使ってプログラミングをしてきた人々は、オブジェクト指向の方法論を理解するのにかなり苦しんだ。もちろん、Smalltalkにも欠点はあった。変わったシンタックスを採用しており、それが一部の人には嫌われた。しかし、その環境と力を目にしたソフトウェアの本当のプロは、Smalltalkをもっと知りたいと考えるようになっていった。
|
本記事は「The Rational Edge」に掲載された「Beyond an objects-first approach」をアットマーク・アイティが翻訳したものです。 |
|
1/3 |
|
INDEX |
||
| RationalEdge オブジェクト指向を超えて |
||
| Page1 ◆ 構造化プログラミングの紹介 |
||
| Page2 ◆ 教育と学習に対するオブジェクト・ファーストのアプローチ |
||
| Page3 ◆ アスペクト指向方法論は次のキーアイテムか? |
||
| IT Architect 連載記事一覧 |
The Rational Edge
米ラショナルソフトウェアがWeb上で毎月更新するオブジェクト指向開発のための論文集「The Rational Edge」を@ITが厳選して翻訳
- 第1回 要件仕様の決定に時間を割かない結末は?
- 第2回 先駆者に学ぶ「開発プロセス改善の原則」
- 第3回 あるプロジェクトリーダーの成功ストーリー
- 第4回 ソフト開発の変革というWebサービスの可能性
- 第5回 プロダクト・マネジメントを成功に導くには
- 第6回 分散コンピューティング時代のテスト手法
- 第7回 プロジェクトの特性に合わせた要件定義手法の選択
- 第8回 優秀なテスターの育成と訓練方法
- 第9回 「アジャイル」「RUP」「Rational XDE」の融合
- 第10回 Dr.ユースケースの “ユースケース人生相談”
- 第11回 Webサービスのテスト技法進化論
- 第12回 要件定義の考古学
- 第13回 チェスとソフト開発、その相関関係を探る
- 第14回 開発計画が破たんするには理由がある
- 第15回 要件定義の管理技術(Lv0〜Lv5)
- 第16回 オン・デマンドの波をキャッチしろ
- 第17回 オープンソース時代のテスト手法、そのノウハウ
- 第18回 オープンソース時代のテスト手法、テストのロードマップ
- 第19回 オープンソース時代のテスト手法、テストのまとめ
- 第20回 『オープン』の正体 (前編)
- 第21回 『オープン』の正体 (後編)
- 第22回 サブシステムの「なに?」「なぜ?」「どうやって?」
- 第23回 サブシステムとはモデリング概念である
- 第24回 アスペクト指向プログラミング オーバービュー
- 第25回 「プロジェクト管理」を管理するために
- 第26回 レッスン1:何もせずに取り残されるな
- 第27回 レッスン3:相違に注意を払え
- 第28回 大規模プロジェクトにアジャイルを適用する方法(前編)
- 第29回 大規模プロジェクトにアジャイルを適用する方法(後編)
- 第30回 アジャイル開発:成熟期の到来、その道のり
- 第31回 UML 2.0のキホン:コンポーネント図の詳細解説
- 第32回 コーディングの知恵を要件定義で利用する
- 第33回 隣のテストチームが優秀ないくつかの理由(前編)
- 第34回 隣のテストチームが優秀ないくつかの理由(後編)
- 第35回 中国のソフトウェア開発現場はこんなにスゴイ
- 第36回 ソフトウェア開発の「いま」と「近未来」の話
- 第37回 ルネサンスの巨匠たちに学ぶエンジニアリングの技
- 第38回 オブジェクト指向を超えて
- 第39回 ユーザー要件を引出すテクニック
- 第40回 ITプロジェクトを見える化する
- 第41回 ソフトウェアアーキテクチャって何なの?(前編)
- 第42回 ソフトウェアアーキテクチャって何なの?(後編)
- 第43回 ソフトウェアアーキテクトの役割
- 第44回 ソフトウェアアーキテクティングのプロセス
- 第45回 ソフトウェアアーキテクティングのメリット
- 第46回 ウォーターフォールから反復型への移行手順
- 第47回 トランザクション管理の複雑性を克服する パート1
- 第48回 トランザクション管理の複雑性を克服する パート2
- 第49回 汎用グラフィカルモデリング言語「SysML」 パート1
- 第50回 グラフィカルなモデル言語で製品構造を記述
- 第51回 キミのコードが汚い理由
- 第52回 「設計」や「構築」よりも重宝されるスキル
- 第53回 専門家に聞くモデル駆動開発のメカニズム
- 第54回 プロジェクトのはじめに計画を立てるのは無謀
- 第55回 「この開発プロジェクトは中止!」の基準
- 第56回 なるほど! ビジネスユースケース
- 第57回 そうだったのか! システムユースケース
- 第58回 不完全なコードは推敲フェイズで潰しておきたい
- 第59回 ビルドが全滅する原因
- 第60回 初歩の「Perl」「Python」「Ruby」
- 第61回 開発プロジェクトを「統治」するベストプラクティス
- 第62回 開発プロジェクト「統治」のピンポイント解説
- 第63回 反復開発の「ここはぜひカバーしたいポイント」
- 第64回 開発プロセス導入のアンチパターン
- 第65回 プロセスはチャンスが訪れるたびに改善する
- 第66回 自己管理型チームの利点と弱点
- 第67回 人事評価と開発者のモチベーション
- 第68回 鈍重な開発チームは鈍重なシステムを作る?
- 第69回 ソフトウェアが複雑なのは仕方がない?
- 第70回 ソフトウェアの複雑性を手なずける
- 第71回 見積もりの精度 Accuracy of Estimation
- 第72回 アジャイル開発の広範な普及を目指して
- 第73回 アジャイルとシステムテストの新たな関係(前編)
- 第74回 アジャイルとシステムテストの新たな関係(後編)
ホワイトペーパー(TechTargetジャパン)
|
|

