はじめに
「オブジェクト指向とは何か簡単に説明してください」と言われてパッと答えられなかったのが悔しかったため、オブジェクト指向についてまとめていく。
オブジェクト指向とはどのようなものか
オブジェクト指向ではデータと手続きを分離せずにそのまま記述できる
「システム構築」とは、「ユーザの要求や目的を満たすべく一連の表現や処理を定義した上でそれを実際に作成すること」である。システムを構築する際には必ず「モデリング」という作業が必要になる。モデリングでは、扱う対象の一部または全部を何らかの形でデータ化した上で、さらにそれに必要な機能を与えるという作業が要求される。
オブジェクト指向の考え方はこうしたモデリングを経て定義される「システムを構成する全てのもの」がデータと手続き（機能）を持った「オブジェクト」として定義できるというものである。
モデリングの対象をオブジェクトとして、データと手続きを分離せずにそのまま記述できることは記述の構造化という大きなメリットをもたらす。
外部に対して情報を隠蔽できる
加えて、単にデータと手続きを一体としてできるだけでなく、それらのオブジェクトへの外部からのアクセスを明示的に制限できる機構を持つことも大きな特徴の一つと言える。外部に対して公開していないデータと手続きは言葉の意味通り外部から一切操作することができなくなる。
これによりオブジェクトを設計する際に外部に対して公開する部分だけを前提にオブジェクトの内部状態を作り込むことができ、このことはオブジェクトを予期しない形で内部データが変化しているような類の危険から未然に守ることができる。
これを「情報隠蔽」という。
オブジェクトを外部から利用する側の立場からしてもオブジェクトを利用する上でその内部構造を全て理解する必要はなく、外部に公開されている部分だけを利用できればそれで良いので、これによりライブラリの利用が促進されるというメリットがある。これを「カプセル化」という。
こうしたオブジェクトの性質は「クラス」という単位で記述が一般化され雛形が定義されるが、オブジェクト指向ではこのクラスに「継承（インヘリタンス）」という関係を定義することにより、重複するデータや手続きをまとめ上げて強固な構造を定義したり、記述を簡略化して再利用を促すことも可能にしている。
オブジェクト指向を用いるメリット
我々がシステムで扱ったり管理したりするのはしばしば現実の「モノ」である。オブジェクト指向ではモデリングの過程において現実との関係なども類推しやすいことも多く、そうした場合には直感的にシステムを把握できるというメリットがある。
そして何よりカプセル化の概念を用いることにより複雑な部分をオブジェクトに内包させたままシステムに組み込むことができるため、一般的には複雑な物に対する記述性が高まる。
これは、扱うモデルが複雑な物であればあるほどオブジェクト指向できちんとモデリングを行うことによるメリットが高まるということもできる。
そして重要なのは我々を取り巻く現実自体が複雑であるという事実であり、したがってモデリングに対する要求が上がれば上がるほど際限なくシステムは複雑になるということである。
コンピュータのハードウェアやソフトウェアは進化を続けている物であり、一度新しい便利な物に慣れてしまうと次はより便利なものを欲しがるというユーザの志向からも今後も複雑になっていく一方であると言える。それがまさに、システム構築を行う者にとってオブジェクト指向が必須である基本技術であり、オブジェクト指向を理解し用いなければならない理由である。
三種の神器
OOA,OOD,OOPとは
オブジェクト指向はその性質上、複雑なシステムを構築するときにこそ本来のメリットを生かすことができる。言い換えれば、複雑なモデリングを行ってこそユーザはその有効性を引き出したシステムを構築することができる。
そして複雑なモデリングはプログラミングの技術だけで構築、運用できるものではなく、オブジェクト指向をプログラミングの手段として用いるだけではその本来のメリットを十分に引き出せているとは言えない。
オブジェクト指向分析(OOA)とオブジェクト志向設計(OOD)とオブジェクト志向プログラミング(OOP)を組み合わせてこそ、初めてその本来のメリットが出せる。
しっかりした分析と設計があってこそのOOP
どんなシステムであっても、システムを構築する上での問題点のほとんどは分析および設計の時点で洗い出せる。分析と設計が適切に行われてこそシステムは健全に構築することができる。分析や設計がめちゃくちゃなシステムの不具合をOOP言語の実装でカバーできるというようなものではない。
逆に分析と設計がきちんとできていれば必ずしもOOPにこだわる必要もそれほどない。分析と設計はオブジェクト指向で行い、実装は非オブジェクト指向言語で行うというアプローチも可能である。
ただし実際には分析と設計がきちんとできていれば実装はその結果をそのまま単純に移すことが可能であるため、分析と設計をオブジェクト指向で行うようなプロジェクトであれば実装もそのままオブジェクト指向で行うことがごく普通であり、この場合には平易かつ高品質な成果を得ることができる。
一番大切なのは設計の技能
部品化（一連のプログラムをまとまった単位で扱えるようにし再利用を促すための技術）や再利用（ある目的のために作成したプログラムなどを別の目的のためにそのまま利用すること）のメリットを得ることを目的としてオブジェクト指向を導入しようと考える人がいるが、実はこれはかなり誤解を生んでいる。
とりわけオブジェクト指向プログラミング言語（例えばJava）で書いたプログラムはあとから再利用できるというのははっきり間違いであると言える。これはとりわけ初心者に落とし穴になる点である。
確かにOOPでの実装においてはそれほど意識しなくても情報隠蔽が普通に達成できるため、比較的内部構造を崩されずにあちこちから使用可能な部品を組むことは容易であり、これはオブジェクト指向のメリットの一つである。
しかしそれが実際に使用されるかどうかは全く別の話である。現実に流通しているライブラリやプログラムモジュールの類は、あるプログラムが（とりわけ第三者から）再利用されるかどうかは以下の条件を満たすことが必須なためである。
- 高い品質を持つこと
- 十分に正規化されたプログラムインターフェースを持つこと
これらはいずれも初心者プログラマが技術を身につけてすぐに作成できるものではなく、OOPであるかすらほとんど関係ない。実装よりもむしろ設計の技能が求められる話であり、とりわけデザインパターン（設計におけるパターンのこと。将棋でいうところの定石）に関する理解は必須である。逆に非オブジェクト指向言語で経験を積んだ熟練プログラマであればオブジェクト指向を学んで直ちにそのメリットを生かすことが十分に可能である。
つまり単に初心者プログラマがOOPを手にしても再利用されない部品ばかり作ってしまう結果になってしまうのはおよそ明白である。
つまり、これからOOPを学ぶ人も、OOAとOODをきちんと学んだ上でOOPでものづくりを行うべきであるということである。
それでこそ再利用をはじめとしたオブジェクト指向のメリットを生かすことが可能になる。
オブジェクト指向に向くもの、向かないもの
現実のシステム開発では最初に作り始めた時点では簡単そうに思えていたことが後になって問題を含んでいることが露見し、思わぬ苦戦をさせられるということがしばしばある。
経験を重ねた技術者であればそのようなやばいところに関する嗅覚が自然に身についているが、いずれにせよこのようなことは往々にして発生し得る。
またシステム開発にはつきものである仕様変更により今は問題なくても将来問題が発生することも珍しくない。
そのような場合に、適切な設計と実装を行った上で強度の高い構造で構築しているオブジェクト指向開発においてはある箇所に関する見直しがシステム全体に波及せず局所的な修正で済むことが多い。おそらくそのようなときにこそオブジェクト指向のメリットを実感することができる。
この意味で全貌を誰にも把握できなくなりそうな大規模なプロジェクトでこそオブジェクト指向であることのメリットは出るし、オブジェクト指向を採用すべきといえる。
これは一番最初の最初にシステムが極々小さく簡単なうちから全ての部分をあとで複雑になっても良いようにきちんとモジュール性を高めた交換可能な構造に作っておく必要があることを意味している（機能ごとにひとかたまりになったプログラムのまとまりをモジュールという。モジュール同士がきれいに分離されており、あるモジュールを別のモジュールに交換してもその影響が他に及ばないような設計はモジュール性が高い）。
これは何も考えず漫然と組むより手間がかかるしきちんとしたやり方にのっとって作る必要があるため最初のうちはかえって面倒に感じるかもしれないが、常にシステム全体を見直せば済むような小規模なプロジェクトの場合には、オブジェクト指向を下手に導入してもかえって手間が増えるばかりの結果になることもありえるため、導入に向かなかったと言える。
参考文献
近藤博次, 図解入門よくわかる最新オブジェクト指向の基本と仕組み, 株式会社秀和システム, 2003年.