もの（オブジェクト）を中心としてモデル化する概念、 またはその概念に基づくシステム構成のことです。
それまでの主流は「手続きを中心に考える」やり方でした。 まず処理の流れを決め、必要なデータを用意する。 オブジェクト指向はこれを裏返し、まず「もの」を決め、そのものができることを与えます。
| 年 | できごと |
|---|---|
| 1960年代 | シミュレーション言語 Simula 67 のデータ抽象概念を発展させ、 「オブジェクト」ということばが生まれた |
| 1980年 | Smalltalk-80 がアラン・ケイによって考え出された。 Smalltalk では「すべて」がオブジェクトとして定義された |
Smalltalk での計算の見え方。
x ← 2 * 3.
これは「2 に 3 を掛けよ」という命令ではありません。
オブジェクト 2 に「*3」というメッセージを送り、
返ってきた結果オブジェクト 6 を変数 x に代入する、と読みます。
計算を「命令の実行」ではなく「ものどうしのやりとり」と見るのが、この考え方の核です。
| 柱 | 中身 | 何がうれしいか |
|---|---|---|
| カプセル化 | データと、それを操作する手続きを 1 つにまとめ、 外からは決められた入口（メソッド）だけを通す | 内部の表現を変えても、外への影響が閉じる |
| 継承 | 既存のクラスの性質を受け継いで、新しいクラスを作る | 共通部分を 1 か所に書ける。差分だけ書けばよい |
| 多相性（ポリモルフィズム） | 同じメッセージに対し、受け手ごとに違う振る舞いをする | 呼ぶ側が相手の種類を場合分けしなくてよい |
第7回で、モジュール強度の最上位は情報的強度 （同じデータ構造を扱う複数の機能を、入口ごとにまとめたもの）でした。 これはカプセル化そのものです。
また、結合度の最上位（最悪）は内容結合
（他のモジュールの内部を直接いじる）でした。
カプセル化は、それを言語の仕組みとして禁じるものだと言えます。
つまりオブジェクト指向とは、「高強度・低結合」を作りやすくするための道具立てです。
| 段階 | やること |
|---|---|
| オブジェクト指向分析 | 問題領域に登場する「もの」を洗い出し、その関係を整理する。 現実の世界に何があるかを写し取る |
| オブジェクト指向設計 | 分析で得たモデルを、実装できる形へ具体化する。 クラス、属性、操作、関連を決める |
分析と設計が地続きなのが利点です。 手続き中心の作り方では、「業務の流れ」と「プログラムの構造」が別物になりがちでした。 オブジェクト指向では、現実の「もの」がそのままクラスになるので、 要求 → 分析 → 設計 → 実装 の間で語彙が変わりません。 第5回で見た「用語がそろわない」問題への、ひとつの答えでもあります。
ものづくりの歴史は、部品を組み合わせる方向へ進んできました。 機械も、電子回路も、はじめは一品ごとの手作りでしたが、 やがて規格化された部品を組み立てる方式に変わりました。
ソフトウェアも同じ道をたどろうとしています。 オブジェクトは、その部品の単位になることを期待されたものです。 この期待が実際にどこまで実現したかは、第11回の再利用で扱います。