nyan, * BPnet * TRENDYnet * ビジネス * PC ...

* BPnet
* TRENDYnet
* ビジネス
* PC
* IT
* テクノロジー
* 医療
* 建設・不動産
* 環境
* 安全・安心
* 経営とIT
* 動画
* 働く女性
* 転職

ITpro selfup

* 様々な職種があるIT業界，そのキャリアプランもいろいろです。徹底インタビューで50の仕事とキャリアをご紹介します
* 「笑ってダマされタメになる！きたみとまなめのIT用語集」好評連載中です！。気になるITのキーワードをマンガと文章で楽しく解説しています

* techup
* システム
* プログラミング
* ネットワーク

* humanup
* パーソナル
* チーム力
* 業務知識
* 健康

* careerup
* 資格
* 就職／転職
* キャリア設計

* BOOKS
* 必修講座100
* eラーニング
* 求人情報
* 編集後記

* selfupとは
* サイトマップ
* メルマガ
* 会員登録・変更

* MyITproについて
* ITproについて
* ITproプレミアム
* 問い合わせ・ご意見
* 日経ＢＰ書店
* 広告について
* 個人情報保護方針/ネットにおける情報収集/個人情報の共同利用について

日経ソフトウエア
特集　オブジェクト指向は難しくない！
オブジェクト指向を正しく理解する
混乱を招く落とし穴に注意しよう
初公開日：2006/11/16
1 2 3 4 次ページへ
印刷 »連載目次へ

　オブジェクト指向はしばしば，とっつきづらく難しい技術と言われます。その理由の一つには，対象とする分野が広く，それぞれに深みがあることが挙げられます。しかし，それ以上にこの技術を難しくしている落とし穴とも言うべき原因が二つあると筆者は考えています。それは比喩を乱用する説明の仕方の問題と，「もの中心」を意味するコンセプト自体の問題です。

　そこで本特集では，「オブジェクト指向という言葉をよく聞くけど，実際どんなものかよくわからない」という方のために，初心者/入門者が陥りやすい落とし穴を明確にしながら，オブジェクト指向の全体像を説明します。余計な先入観やまぎらわしいたとえ話に惑わされなければ，オブジェクト指向そのものはそれほど難しい技術ではないことを理解していただきたいと思います。なお，オブジェクト指向プログラミング，デザインパターン，分析/設計といった個々の技術については特集2以降でそれぞれ解説します。
オブジェクト指向が登場した背景

　オブジェクト指向は，英語では“object oriented”であり，「もの指向」「もの中心」といった意味を持ちます。一言で表現するなら「オブジェクト（もの）中心に考えるソフトウエア開発手法」と言えるでしょう。

　従来の開発手法は，ソフトウエアが実現する「機能」に着目しました。最初に全体として実現する機能を定義し，それを徐々に細かい機能に分割していくのが基本的なやり方です。この手法は「構造化分析/設計手法」として体系化されており，長い間主流として使われてきました。

　オブジェクト指向では全体の機能を一枚岩ととらえずに，データと手続きを持った「オブジェクト」の集まりとしてとらえます。ソフトウエア全体として機能を実現するだけでなく，保守性や再利用性に配慮して，個々の部品の独立性も重視するわけです。

　こうした考え方が重要になった背景には，ソフトウエアが大規模で複雑になったことがあります。以前のソフトウエア開発では，毎回ほとんどゼロからプログラムを作り直していました。しかしそうした方法では，品質の高いソフトウエアを短期間で作ることは困難なため，既存の部品を再利用することが重要になってきました。また，いったん作ったソフトウエアに修正を加えて長く使い続けるケースも増えてきました。ソフトウエアを保守しやすくするには，個々の部品の独立性を高くして，全体の見通しを良くし，修正の影響範囲を局所化する必要があります。こうしたニーズからオブジェクト指向が注目されるようになりました。
正しい理解を妨げる落とし穴

　オブジェクト指向という考え方は，目に見える「もの」を中心に現実世界を識別する人間にとって，自然な考え方であると説明されることもあります。にもかかわらず，オブジェクト指向は難しい技術だと言われます。その理由の一つとして，オブジェクト指向がソフトウエア開発の幅広い分野を対象にしていることが挙げられるでしょう。抽象的な考え方が求められるから難しいのだという意見を聞くこともあります。

　しかし筆者には，どうもそれだけが原因とは思えません。筆者は過去に，オブジェクト指向と哲学を対比する説明や，「オブジェクト指向を使えば現実世界をそのままプログラムに表現できる」といったちょっと不思議な説明を聞く機会が時々ありました。そうした聞き手の意表を突く話は，何かおかしいと感じながらも，思わず受け入れてしまいがちです。そうした経験から考えると，難しいというよりも混乱していると解釈するほうが適切に思えます。

　以降では，そうした混乱を引き起こしている原因として「比喩の乱用」と「強力過ぎるコンセプト」の二つの問題を説明します。この二つは，オブジェクト指向の正しい理解を妨げる落とし穴と言えるでしょう。「オブジェクト指向は難しくてよくわからない」と思っている方は，ぜひその先入観を捨てて，白紙の気持ちで読み進めてください。
比喩の乱用が混乱を引き起こす

　一つ目の落とし穴は「比喩の乱用」です。これは，技術そのものと言うよりも，説明の仕方に起因する問題と言えるでしょう。

　オブジェクト指向プログラミングの仕組みは，しばしば現実世界と対比して説明されます。こうした説明が理解を助けるためのたとえ話であることを明示しないケースをよく見かけます。例えば，次のような説明です。
説明1－クラスとインスタンス

　「クラス」は種類で，「インスタンス」は具体的なものを表す。犬を例に取れば，一般的な“犬”が「クラス」で，“タロー”“ポチ”“マル”などの具体的な犬が「インスタンス」に相当する。犬が共通に持っている“名前”“年齢”などの性質を「属性」と呼び，“鳴く”“エサを食べる”“寝る”といった共通な振る舞いを「メソッド」と呼ぶ（図1）。
図1●クラスとインスタンス。一般的な“犬”が「クラス」で，“タロー”“ポチ”“マル”などの具体的な犬が「インスタンス」に相当すると説明されることがある
説明2－メッセージ・パッシング

　オブジェクト指向言語を使って書かれたプログラムは，インスタンス同士がメッセージを送り合って動作する。この仕組みは，飼い主が飼い犬に対して“鳴け”とメッセージを送ると“ワン”と応える様子に相当する（図2）。
図2●メッセージ・パッシングのイメージ。飼い主が飼い犬に対して“鳴け”とメッセージを送ると“ワン”と応える様子に相当するというが，現実にはメッセージに応えない犬もいるだろうし，命令されなくても吠える場合もある

　こうした説明は，オブジェクト指向プログラミングの仕組みを直感的に理解するのには適しています。しかし，実際にはこの説明は正しくありません。オブジェクト指向のプログラムの世界では，犬クラスにnew指令を送ることで個々のインスタンスが作られますが，現実世界の犬が生まれるのは妊娠したメス親が出産するからです。また，プログラムのインスタンスは，メッセージを受けると必ず仕事をします（反対に，メッセージを受けるまでは，ただじっと待ち続けています）。これに対して，現実世界の犬は，“鳴け”と命令されても機嫌が悪ければ飼い主を無視するでしょうし，命令されなくても鳴きたければ自分の意志で勝手に鳴くでしょう。

　このようにオブジェクト指向プログラミングの仕組みと現実世界は，実はずいぶん違います。とはいえ確かに共通する点もあります。そこで，混乱を避けるためには，両者を「よく似たもの」と考えずに「似て非なるもの」と割り切ったうえで，現実世界との対比による説明はたとえ話と解釈するのがコツです。

page: 2
「もの中心」というコンセプト自体が落とし穴

　オブジェクト指向の正しい理解を妨げるもう一つの落とし穴は「もの中心」というコンセプトそのものです。

　このコンセプトは，シンプルながら非常に強力です。強力すぎて副作用があります。それは，この考え方がプログラム以外の森羅万象に適用できてしまうことです。

　例えば，身の回りにある本やパソコンから，友人や憧れの芸能人，企業や国，大陸や星，宇宙にいたるまで，なんでも「オブジェクト」と考えることができます。そんな風に考えると，「もの中心」という考え方がまるで森羅万象を説明する真理であるかのように思えてしまうことでしょう。確かにそうした考え方も面白いかもしれません。しかし，この考え方だけを使って，コンピュータを動かすソフトウエアの仕組みを説明しようとするのは無理があります。実際には，先ほど説明したように，プログラムの世界の「クラス」や「インスタンス」は現実世界の動物や物とは「似て非なるもの」です。

　ところが，まぎらわしいことに，オブジェクト指向はプログラミングだけでなく，業務分析や要求定義などの上流工程もカバーします。そこでは，現実世界の人の仕事や，組織・商品の仕組みなどを整理しますが，そうした場合でもクラスやインスタンス，メッセージなどの仕組みを適用します。ただし，そこではオブジェクト指向プログラミングの仕組みをそのまま適用するわけではなく，あくまで「応用する」だけです。

　ここがなんともまぎらわしいところなのです。ここまでの説明を読んで混乱してきた方もおられることでしょう。それもそのはずです。何しろここはオブジェクト指向技術自体が混乱しているところですから。

　きちんと説明しましょう。ここまで書いてきたように，現実世界とオブジェクト指向プログラミングの仕組みは「似て非なるもの」です。そして，このプログラミングの仕組みを現実世界の様子を整理する上流工程に適用した結果，微妙に解釈が変化することになりました。つまり，上流工程において，クラスの仕組みは「集合論」になり，メッセージ・パッシングの仕組みは人や企業が共同で仕事を進める「役割分担」の仕組みになったのです（図3）。オブジェクト指向は上流工程で「汎用の整理術」に変化したと言えるでしょう。
図3●クラスは集合論に，メッセージ・パッシングは役割分担に応用された
[画像のクリックで拡大表示]

　結果として，オブジェクト指向の適用範囲は大きく広がりました。コンピュータ内で複数のスレッドがメッセージを送り合って連携するメカニズムの設計に応用できるのはもちろんのこと，実際の人間の仕事を整理する業務分析，現実世界の出来事や登場人物/物事を記録するためのデータ・モデリング，企業内の組織の役割分担，複数企業が連携してビジネスを行うSCM（Supply Chain Management）の表現――などいろいろな分野に応用可能になりました。
「プログラミング技術」と「汎用の整理術」の二つの顔

　このようにオブジェクト指向の対象範囲は大きく広がった一方で，混乱も持ち込むことになりました。何しろオブジェクトやクラスという用語は，ある場面では現実世界の人間や物を指し，別の場面ではコンピュータの中で動くプログラムの仕組みを指すわけです。そして先ほど述べたような，比喩を使ったプログラムの仕組みの説明が，さらに事態を悪化させることになりました。

　「オブジェクト指向を使えば現実世界をそのままプログラムに表現できる」といった誤解や，「オブジェクト指向は難しいので，何年も修行を積まないと習得できない」といった極端なとらえ方をされる原因はそこにあります。こうした状況に惑わされないために，次のことをぜひ頭に入れておいてください。
(1)オブジェクト指向プログラミングの仕組みと現実世界は「似て非なるもの」である。
(2)オブジェクト指向には，「プログラミング技術」と「汎用の整理術」の二つの側面があり，これらも別物である。
プログラミング言語から総合技術に発展した

　前述の通り，オブジェクト指向は「もの中心」を基本とする開発手法です。しかし，実際にオブジェクト指向と呼ばれるプログラミング言語（Object Oriented Programming Language）が登場したのは，「もの中心」というコンセプトが作られるより前のことです＊1。

　このプログラミング言語は，それ以前の言語にはない三つの仕組みを備えていました。それは「カプセル化」「継承」「ポリモーフィズム」と呼ばれるもので，これらを称して「オブジェクト指向の三大要素」と呼ぶことがあります（カコミ記事「オブジェクト指向の三大要素とは」を参照）＊2。

　これらの仕組みが優れていたため，従来の言語では実現できなかった大規模な再利用部品群を作ることが可能になりました。こうした再利用部品群は，クラスライブラリ，フレームワーク，コンポーネントなどと呼ばれます。具体的には，Javaや .NETに付属するクラスライブラリ，J2EEで作るWebアプリケーション用のStrutsフレームワークやEJBコンポーネントなどがそうです。

　また先駆者たちは，オブジェクト指向プログラミング言語の優れた仕組みを利用して，再利用性の高いソフトウエアを作るための共通のノウハウがあることを互いに認識し，それをお決まりの設計パターンとして整備しました。これがデザインパターンです。

　さらに，上流工程の分野では，オブジェクト指向の仕組みが「汎用の整理術」として応用され，モデリング技術になりました。モデリングとはその名の通りモデルを作ることです。大規模なソフトウエアは，多くの人々が協力して，何カ月も何年もかけて開発しなければなりません。モデリングは，そうしたコストや労力をかける前に，青写真として「モデル」を作ることで，ビジネスの仕組みやシステムへの要求仕様を整理して確認する技術です。このモデルは2次元の図に表現しますが，こうした図式表現はUML（統一モデリング言語）として国際標準になっています。

　それだけにとどまらず，ソフトウエア開発を柔軟に進めるための反復型の開発プロセスまでもがオブジェクト指向の範ちゅうに含まれます。

　このように，最初にプログラミング言語として登場したオブジェクト指向は，ソフトウエア開発の様々な分野に応用されて，ソフトウエア開発全体をカバーする総合技術になりました（図4）。
図4●オブジェクト指向は，ソフトウエア開発全体をカバーする総合技術に発展した

オブジェクト指向の三大要素とは

　オブジェクト指向の三大要素とは，「カプセル化」「継承」「ポリモーフィズム」です。三大要素という言葉は，オブジェクト指向プログラミング言語の優れた仕組みを説明するための表現です。この三大要素はオブジェクト指向においてもっとも基本的かつ重要な技術であり，その仕組みをきちんと理解しておくことは非常に重要です。
カプセル化

　カプセル化（encapsulation）は「カプセルに詰めること」を意味します（図A）。オブジェクト指向プログラミングでは，複数のメソッド（サブルーチンや関数）と複数の変数を一つにまとめてクラスとして記述する仕組みを指します。単にまとめるだけでなく，メソッドや変数にアクセスできる対象を特定の範囲内に限定することも可能です。つまりカプセル化は，メソッドと変数をまとめて大きなソフトウエア部品を作り，かつアクセス範囲を限定して部品の独立性を高めるための仕組みと言えます。
図A●カプセル化（クラス）の仕組み

　クラスにはもう一つの重要な特徴があります。それはインスタンス生成です。クラスを定義すると，実行時にそこからいくつでもインスタンスを作れます。「インスタンスを作る」とは，クラスに定義した変数領域を新しくメモリー上に確保することを指します。それぞれのインスタンスは互いに干渉しないため，文字列やファイル，顧客や商品情報など同じ形式の複数の情報を処理するロジックを単純に記述できます。
継承

　継承はinheritanceの訳語です。あるクラスのメソッドや変数などの定義情報を別のクラスに取り込む仕組みです（図B）。よく似たクラスを作るときに共通部分を定義したクラス（これをスーパークラスと呼びます）を用意し，それを「継承する」と宣言するだけで，定義情報をそのまま利用できるようになります。
図B●継承の仕組み。サブクラスは「継承する」と宣言するだけで，スーパークラスのインスタンス変数とメソッドをすべて定義したことになる
ポリモーフィズム

　ポリモーフィズム（polymorphism）は，日本語では「多態性（たたいせい）」と訳すのが一般的です。この仕組みを一言で表現するなら「呼び出す側を共通化する」仕組みと言えるでしょう（図C）。従来は，呼び出される側を共通化する共通サブルーチンしかありませんでした。呼び出す側を共通化するポリモーフィズムの仕組みは，ソフトウエアに大きな柔軟性をもたらすことになりました。現在フレームワークと呼ばれる大規模な再利用部品があるのは，この仕組みのたまものと言えます。
図C●ポリモーフィズムの仕組み

page: 3
オブジェクト指向に関係ない技術も取り込んだ

　ところで，面白いことにオブジェクト指向の中には，「プログラミング技術」と「汎用の整理術」のどちらにも当てはまらない技術もあります。

　その代表的なものはUMLで定義されている「ユースケース」です。読者の中には，ユースケースをオブジェクト指向の固有概念と考えている方もいるかもしれません。しかし，ユースケースはシステムが実現する機能の固まりであり，従来は外部仕様やサービス機能などと呼んでいたものです。その風変わりな名前を除けば，ユースケースは，従来から当たり前に使われてきた考え方と言えるでしょう。

　同様に，UMLの「ステートマシン図」も，通信制御システムや組み込みシステムなどの分野で従来から広く使われてきた図です。また，フローチャートの変形である「アクティビティ図」は，本来は「構造化分析/設計手法」で使われる機能分割を表現する図です。このようにUMLはソフトウエア業界で古くから使われてきた有用な図式表現を取り込んだため，オブジェクト指向とは直接関係ないものも含んでいます。

　RUP＊3やXP＊4といった反復型の開発プロセスも，オブジェクト指向の考え方や仕組みとは直接関係ありません。こうした開発プロセスは，より柔軟にシステム開発を進めていくことを目指したものであり，保守性の高いオブジェクト指向だからこそ適用できる技術であると説明されることがあります。しかし実際には，柔軟な開発プロセスが可能になったのは，ハードウエアの進歩による開発環境の向上も大きく寄与しており，「もの中心」という考え方とはさほど深い関係はありません。

　このようにオブジェクト指向が，直接関係ない技術を取り込んでしまったことも，理解を難しくしている要因と言えるでしょう。
ソフトウエア開発をラクにする技術

　ここまでの話で，オブジェクト指向が「もの中心」という単純な考え方だけに基づく技術ではないことを理解していただけたでしょうか。もしかすると「混乱を避けるコツはわかった気がするけど，やっぱりなんだか難しそう」と思った方もいるかも知れません。しかし，心配は無用です。実際にプログラミングをしたり，UMLの図を書いてみたりすれば，一つひとつの技術が決して難しいものではないことを実感できるはずです。

　現在のオブジェクト指向を一言で表現するならば，「品質が高く，保守や再利用がしやすいソフトウエアを開発するための技術の集大成」と言えます。この技術には先人たちの知恵や努力の成果が凝縮されています。この技術を習得し，提供される道具を使いこなすことで，従来よりラクに開発することができます。

　オブジェクト指向は，開発がラクになるだけでなく，知的好奇心を刺激するとても面白い技術です。筆者は以前，ソフトウエア開発の現場から早く卒業し，管理職になることで“ラクをしたい”と思っていました。しかしオブジェクト指向に出会ってからは，ソフトウエア開発の仕事が以前よりも楽しいと思えるようになりました。

　また，オブジェクト指向に含まれる個々の技術は決して目新しいものばかりではありません。日頃から品質の良いソフトウエアを作ろうと工夫している方ならば，自分が考えたのと同じアイデアをいくつも発見できることでしょう。そんな方からすれば，この技術はきっと宝の山に見えるはずです。

page: 4
オブジェクト指向の素朴な疑問にお答えします

ここまででオブジェクト指向を正しく理解するコツとオブジェクト指向の全体像を説明しました。ここでは前節で説明しきれなかったことをQ&A形式で解説したいと思います。
Question
「オブジェクト指向」は誰が考えたのですか？

　「オブジェクト指向」という言葉は，Smalltalk（スモールトーク）の開発を指揮し，コンセプト・メーカーでもあるAlan Kay氏が付けたものだそうです。Kay氏は，1970年代に米Xeroxのパルアルト研究所に在籍した当時，ワークステーションの元祖を考案し，純粋なオブジェクト指向言語として現在でも根強い支持を受けているSmalltalkの開発を指揮しました。

　Smalltalkは当時無名だったSimula67の仕組みを取り入れました。そしてその仕組みを拡張・発展させ，Objectクラスを最上位とする継承構造によるクラスライブラリや，MVC（Model-View-Controller）フレームワークを生み出しました。この言語は，Javaとは違って基本データ型がなく，数値や真偽値を含むすべてのデータ型をオブジェクトとして扱います。そして四則演算や論理演算もメッセージ・パッシングとして実現しているところに大きな特徴があります。この斬新な仕組みが「オブジェクト指向」の発想を広げ，今日の大きな発展をもたらしたと言えるでしょう。

　最近では，Squeak（スクイーク）というSmalltalkの実装環境が広まっており，根強い人気を博しています。しかし，Smalltalkがビジネス・アプリケーションや組み込みソフトウエアの開発言語として使われるケースはまれです。その理由は，あまりに先進的な言語であるため，2005年時点でもまだ未来の言語だからなのかもしれません。
Question
なぜオブジェクト指向言語が
主流になったのですか？

　現在，UNIXやWindows上で稼働する企業向けシステムの開発・実行環境は，Javaと .NETが2大勢力になっています。これらはいずれもカプセル化，継承，ポリモーフィズムの仕組みを基本とするオブジェクト指向言語を採用していますが，その理由はたんに流行しているからといった単純なものではありません。本質的な理由が二つあります。一つはソフトウエア開発へのニーズの変化であり，もう一つはハードウエア能力の劇的な向上です。

　まず，ソフトウエア開発へのニーズの変化から説明しましょう。コンピュータは誕生した当時，政府機関や一部の大手企業など，限られたユーザーが特定の用途で利用する非常に高価な機械でした。しかしその後，様々な分野に広まり，用途も単純なバッチ処理から，端末と通信回線で接続してデータベース上の情報にアクセスするオンライン・システムが中心になりました。個人用のパソコン上で動作する各種のアプリケーションや，電気製品や制御用機器を動かす組み込みソフトウエアも登場しました。このように対象範囲が広がるのと同時に，ソフトウエアは複雑化・大規模化していきました。

　それにもかかわらず，オブジェクト指向以前のソフトウエア開発では，アプリケーションの多くを毎回ゼロから作り直していました。これはCOBOL，FORTRAN，C言語などの従来のプログラミング言語では，再利用の基本的な単位がサブルーチン（関数）だったことが大きな原因と言えるでしょう。また，いったん作ったアプリケーションに修正を加えて使い続けるケースも増えてきました。このような状況から，正しく動くプログラムを作るだけでなく，できあがったプログラムを修正しやすくすること，そしていったん作った品質の良いプログラムを使い回すこと，すなわち保守性と再利用性が非常に重要になりました。1995年に登場したJavaが一気に普及した背景にはこんな必然性がありました。

　もう一つの理由は，ハードウエア能力の劇的な向上です。これはオブジェクト指向が普及した直接の理由というよりも，普及を妨げる障害を取り除いたと言うべきかもしれません。オブジェクト指向言語は，柔軟性と引き替えに，CPUやメモリーなどの資源を余分に消費します。実行時にメモリーを動的に確保したり，メソッド（関数）を呼び出す際にメソッド・テーブルを経由する仕組みになっているからです。以前はこうした仕組みによるオーバーヘッドが無視できませんでしたが，ハードウエア能力が劇的に向上したことで，全体としては大きな問題でなくなりました。

　なお，オブジェクト指向とは直接関係ありませんが，ハードウエア能力の向上が実現可能にしたソフトウエアの再利用を推進するもう一つの機構として，仮想マシンがあります。この仕組みは，Javaや .NETで採用しており，機種やOSの仕様の違いを吸収し，異なる環境下で同じプログラムを動作可能にするものです。この仕組みはアプリケーションの可搬性を保証するだけでなく，ソフトウエア部品の再利用範囲を大きく広げた点でも画期的です。このようにハードウエア能力の進歩のおかげで，保守性や再利用性の向上を目的とした，より柔軟な仕組みが実用レベルの技術になりました。

　ソフトウエアの大規模化・複雑化に伴って保守性と再利用性が重要になったことからオブジェクト指向言語へのニーズが高まり，進歩したハードウエア能力がオブジェクト指向などの技術の普及を後押ししたと言えるでしょう。
Question
オブジェクト指向を採用すれば，
本当に保守性や再利用性が向上するのですか？

　オブジェクト指向は，採用しただけで保守性や再利用性が向上する魔法の技術ではありません。しかし，うまく使いこなせば保守性や再利用性を向上できる優れた道具です。

　前節で述べたように，オブジェクト指向はたくさんの技術から成り立っています。これには，Java，C#，Rubyなどのプログラミング言語，フレームワークやクラスライブラリと呼ばれる大規模な再利用部品群，優れた設計のアイデアを整理したデザインパターン，設計情報を図式表現するUML，プロジェクトを柔軟に進めるアジャイル開発プロセスなどがあり，いずれも先人たちの知恵や経験から生まれた優れた技術やアイデアです。

　しかし，優れた技術ではあるもののすべて道具です。立派な道具があれば良い製品を必ず作れるわけではないのと同様に，オブジェクト指向を採用したからといって優れたソフトウエアが無条件にできるわけではありません。下手に使うと逆効果になることさえあります。不適切な箇所で継承やポリモーフィズム，デザインパターンなどを使えば，複雑になるだけで，かえってわかりづらくなるでしょう。

　大事なのは目的です。そのソフトウエアに対して，将来どんな仕様追加が入りそうか，どんな機能を別のシステムで再利用したいかといったことをある程度想定し，それに対処するためにオブジェクト指向技術を適用する必要があります。

　目的を明確にし，保守性や再利用性を向上させようとする意志を持って適材適所で利用すれば，オブジェクト指向は必ず役に立つはずです。
Question
オブジェクト指向開発は
実際の現場でどれくらい普及していますか？

　これはよく聞かれる質問です。一口にオブジェクト指向といっても，ここまで説明してきたように様々な技術があるため，単純にYes/Noで答えるのは難しいものがあります。そこで，オブジェクト指向の個々の技術の普及度合いについて，筆者の独断による評価を表1にまとめました。
表1●筆者の独断による，オブジェクト指向技術の普及度合い

　全体としてみれば，プログラミング技術としてのオブジェクト指向については，開発の現場でかなり定着したと言えるでしょう。今や開発環境の主流はJavaや .NETになりましたし，オープンソースなどのソフトウエア・フレームワークを採用するのも珍しくなくなりました。

　しかし，アプリケーション自体にデザインパターンを駆使して，オブジェクト指向らしい設計をしたり，要求定義段階でのUMLモデリングやアジャイル開発プロセスを実際のアプリケーションで適用するケースはまだ少ないようです。

　ただし，この「オブジェクト指向らしい設計」は曲者です。筆者の経験でも，オブジェクト指向を採用してうまく進まないプロジェクトの多くは，「オブジェクト指向自体を目的にしてしまうこと」でした。特に設計レビューなどで「この設計はオブジェクト指向らしくない」という意見が出て，担当者が首をひねっていたら危険なサインです。「オブジェクト指向らしい設計」などと言われても，実際にはどうしたらいいかよくわかりません。先ほどから何度も書いているように，オブジェクト指向は，品質が良く，保守性や再利用性が高いソフトウエアを作るための手段です。保守や再利用の具体的なケースをある程度想定して，その目的に合わせて適材適所で必要な技術を使うことが大切です。

　英語のobjectには，「もの」だけでなく「目的」という意味もあります。「オブジェクト指向」の前に「目的指向」が重要なことを肝に銘じておきましょう。
Question
オブジェクト指向とアジャイル開発は
どういう関係がありますか？

　結論から言えば，オブジェクト指向とアジャイル開発プロセスとの間には，直接の関係はありません。ただし，オブジェクト指向とアジャイル開発プロセスとには間接的な関係があります。その関係は大きく二つあると思います。

　一つ目は，オブジェクト指向による開発技術の進歩が，アジャイル開発プロセスを可能にしたという側面です。アジャイル開発プロセスは，イテレーションと呼ばれる1週間から1カ月程度の短い期間を単位として，それを複数回繰り返しながら段階的にソフトウエアを開発する手法です。こうした開発をうまく進めるには，既存の部品を使い回すなどして，手早くソフトウエアを作る必要があります。また要求定義，設計，実装，テストのサイクルを何度も繰り返すわけですから，いったん作ったソフトウエアに対してどんどん修正や新機能を加えることになります。オブジェクト指向プログラミング，再利用部品群，デザインパターンなどの技術は，高品質で保守や再利用がしやすいソフトウエアを手早く作るための開発手法ですから，アジャイル開発プロセスと相性がいいのは当然です。

　オブジェクト指向とアジャイル開発プロセスのもう一つのかかわりは，提唱者が同じであることです。アジャイル開発は，様々な人が提唱した柔軟な開発プロセスの総称ですが，これらの開発プロセスの提唱者の多くは，デザインパターンやUMLモデリング，リファクタリングといったオブジェクト指向技術を提唱し実践している人たちです。これはソフトウエア開発をうまく進めようとすると，個々の技術を利用するだけでは十分ではなく，仕事の進め方やチームワーク，メンバー間のコミュニケーションといった要素も非常に重要であることを，オブジェクト指向技術の提唱者たちが認識したからでしょう。

　このように，オブジェクト指向とアジャイル開発プロセスの間には直接的な関係はありませんが，間接的には大きなつながりがあります。
Question
オブジェクト指向は
どうやって学ぶのがおすすめですか？

　プログラミング言語から始めてデザインパターン，UMLと進むのがおすすめのコースです。

　最初に学ぶべきことはプログラミング言語の仕組みです。これはオブジェクト指向の基本がプログラミング言語にあるからです。そのためには，プログラミング言語の文法を頭で覚えるだけでなく，自分で実際にプログラミングして動かしてみることが大切です。

　前節で触れたように，オブジェクト指向の仕組みを現実世界になぞらえた説明などを見聞きして，理屈だけで理解しようとすると混乱しがちです。しかし実際にプログラミングをしてみると，それほど難しいものではないことがわかります。筆者の周囲を見ても，日頃からプログラミングをしている若手のエンジニアたちには，オブジェクト指向の仕組みと現実世界の違いで混乱している人はまずいません。オブジェクト指向プログラミングの仕組みを体で理解できているからだと思います。したがって，プログラミングを担当しないベテランの方でも，一度は自分でプログラミングしてみることをおすすめします。カプセル化（クラス），継承，ポリモーフィズムの仕組みを使ってプログラムを書き，デバッガを使って1行ずつ動かしてみれば，ただのプログラミング技術であることが実感できるでしょう。

　おすすめのプログラミング言語は，やはり現在主流のJavaやC#でしょう。これらは言語仕様が比較的単純ですし，C言語に慣れている方なら書き方がよく似ているので違和感も少ないでしょう。たくさんの解説書があるのもメリットです。手軽に使って動かすなら，特集2で紹介するスクリプト言語のRubyがいいと思います。

　オブジェクト指向プログラミングの基本的な仕組みを理解したら，次のステップはデザインパターンです。Javaや .NETなどの環境で本格的なプログラミングをしようとすると，それらに付属する膨大なクラスライブラリを使いこなす必要があります。クラスライブラリは，過去から蓄積されてきたノウハウを活用して作られているため，設計ノウハウの結晶であるデザインパターンが道しるべとして役に立ちます。

　Javaの例で言えば，イベントリスナ（EventListener）やファイル読み込みで使うFilterInputStreamなどは，一見するとかなり複雑な仕組みに思えるでしょう。しかし，基本となっているObserver（オブザーバ）やDecorator（デコレータ）といったデザインパターンを理解してしまえば，その応用であることがすぐわかるはずです。

　次のステップはUMLですが，それは次の質問の回答で説明します。
Question
UMLをうまく使えるようになるためには
どうすればいいでしょうか？

　ソフトウエア開発においてUMLを使う場面は，大きく二つあります。外部仕様を決める要求定義段階と，ソフトウエアの内部構造を決める設計段階の二つです。

　いずれの場合でも，UMLで書いた図は，最終的にプログラムとして記述する前の中間成果物であるため，何をどこまで書くべきかの判断は多少難しいところがあります。またUMLを使ってきちんと設計したつもりでも，いざプログラミングをしてみると，思い違いや抜けに気付くこともしばしばです。

　そこで，特に初心者の方向けに，ちょっと変わった学習法をお教えします。それは，できあがったプログラムを理解するためにUMLを使う方法です。「できあがったプログラムを理解したいならソースコードを読めば十分じゃないか」と思われた方もいるかもしれませんね。でも本当にそうでしょうか？
図5を見てください。これはJavaに含まれるコレクションにかかわるクラス図です。長方形はクラスまたはインタフェースを表し，白ヌキ三角の矢印付きの実線はextends（継承）関係を，同じく白ヌキ三角の矢印付きの点線はimplements（実現）関係を表現しています。
図5●Javaに含まれるコレクションにかかわるクラス図
[画像のクリックで拡大表示]

　試しに図5の左下のほうにあるArrayListクラスのextends関係を上にたどってみてください。AbstractListというスーパークラスがあり，その上位にはさらにAbstractCollectionというスーパークラスがあることがわかるでしょう。また同じArrayListのimplements関係をたどれば，ListとCollectionというインタフェースが関係していることがわかります。図の全体を眺めてみると，左側のCollection以下の階層と，右側のMap以下の階層には直接のつながりがまったくないこともわかります。

　一方，こうした関係を19本のJavaプログラムのソースコードから解析して，頭の中だけで理解することを想像してみてください。よほど天才的な記憶力を持つ人でもない限り，頭の中がスパゲッティ状態になってしまうことでしょう。

　このように既存のプログラムに対して，UMLのクラス図を書くことで，全体のクラス構造を一目瞭然のものとして見渡し，イメージとして記憶しやすくなります。最初からソースコードがあるわけですから，図を書き間違った場合を除いてUMLの図とソースコードが後から食い違う心配も要りません。UMLの図を書き過ぎてかえってわかりづらくなるといった心配も少ないでしょう。UMLは，できあがったプログラムの構造を調べて理解する場面でも非常に強力な道具なのです。

　こうした使い方に慣れてきたら，次はプログラムを作る前の設計情報として書いてみるといいでしょう。UMLを使うことで，頭の中だけで考えるよりも，ソフトウエアの全体構造や役割分担を考えやすくなります。詳細なロジックを考える場合はUMLを使わずにプログラミングを書いてしまうほうが手っ取り早いでしょう。

　最近ではソースコードと連動するUMLエディタも増えてきたため，以前に比べてこうした作業もやりやすくなりました。ただし，どんな環境を使うにせよ，図を使って直感的に全体を理解するためのUMLと，実際にコンピュータを動かす命令を厳密に記述するプログラムの性質をうまく使い分けることが大切です。
平澤章

»「もの中心」というコンセプト自体が落とし穴
1 2 3 4 次ページへ »連載目次へ
出典：日経ソフトウエア 2005年6月号　48ページより
（記事は執筆時の情報に基づいており，現在では異なる場合があります）
コメント ITproブックマーク Hatenaブックマーク Yahoo!ブックマーク Livedoorクリップ印刷
selfupのトピックス

-PR-

* 【ＩＴ業界を目指す学生の皆さんへ】ＩＴ業界徹底研究サイトオープン！
* なぜITの現場は炎上するのかあなたを成功に導く14事例の教訓
* IT営業にすぐ活かせる 4つの技術と実践テクニック