エンジニアの考え方 外伝 - オブジェクト指向の中身を、実務の言葉で

この回は外伝です — 少しだけエンジニア寄りに

このシリーズは「エンジニアでない人が読んでも分かるように書く」と約束して始めました。#3で連想の地図を描き、#4で地図の線に is-a / has-a という名前を付けて、オブジェクト指向の入り口までたどり着きました。

ここから中に入ると、話はどうしてもエンジニア寄りになります。なので今回は外伝として、約束を一回だけ緩めます。オブジェクト指向の中心概念——クラス・カプセル化・ポリモーフィズム——を、文法書の順番ではなく「実務で何が嬉しいのか」という順番で歩く回です。比喩は引き続き使うので、エンジニアでない人も雰囲気は追えるはずです。

クラス —「扱いの約束」を1か所に書く場所

#4で、クラスとは「分類に付けた名前」だと書きました。実務での実体は、もう少し具体的です。その分類に属するもの全部の「データと扱いの約束」を、1か所にまとめて書いておく場所。

紙の世界でいえば、「請求書」フォルダを作るだけでなく、フォルダの表紙に「このフォルダの書類は、確認→支払→保管の順で処理する」という手順書を貼っておくイメージです。図にするとこうなります。

classDiagram
    class 請求書 {
        +金額
        +支払期日
        +確認する()
        +支払う()
        +保管する()
    }

上半分が持っているデータ、下半分がその扱い方。教科書にある「データと、それに対する操作をひとまとめにする」という定義は、この「分類ごとに約束を1か所へ」の言い換えです。嬉しさは変更のときに出ます。処理のやり方が変わっても、直すのはこの1か所。約束が担当者それぞれのメモに散らばっていたら、変更のたびに全員のメモを直して回ることになります。

カプセル化 — 変更コストの正体は「影響調査」

ソフトウェアの変更で一番時間を食うのは、実はコードを書き換える作業ではありません。「ここを直すと、どこが壊れうるのか」を調べる作業です。全員がどこにでも触れる作りだと、この調査が毎回システム全域に及びます。

カプセル化は、これを構造で断ち切る仕組みです。外に見せる面（公開する操作）と、隠す中身（内部のデータや処理）を分けて、中身には外から触れないように壁を作る。宅配便で言えば、配達員は荷物の中身を知らなくていい、という「知らなくていいことの取り決め」を、コードの上で強制するものです。

壁があると、「外に見せる面を変えていないなら、外への影響はない」と構造が保証してくれるので、調査そのものが要らなくなります。電子レンジの中の回路を総入れ替えしても、ボタンの並びが同じなら使う人に連絡は不要——あれと同じことをコードでやっています。

ポリモーフィズム —「呼ぶ側が変わらない」が本領

#4の雨具のように、共通の形をくくり出すと何が起きるか。コンビニのレジ・自動販売機・ネット注文を「販売チャネル」とくくった例で、図にします。

classDiagram
    class 販売チャネル {
        <<interface>>
        +今日の売上()
    }
    販売チャネル <|.. レジ
    販売チャネル <|.. 自動販売機
    販売チャネル <|.. ネット注文

売上を集計する側は、「すべての販売チャネルから、今日の売上を受け取る」と一言で書けます。レジはレジのやり方で、自販機は自販機のやり方で数字を出すけれど、集計側はその違いを知らなくていい。

本領は追加のときです。新しい販売チャネルが増えても、「今日の売上を答えられる」という約束さえ守っていれば、集計側のコードは1文字も変わりません。人間のチームでも、「各自のやり方でいいから金曜までに進捗を報告して」と言える上司は、メンバーが入れ替わっても自分のやり方を変えずに済みます。抽象に話しかけて、具体が各自のやり方で応える——この構図の名前がポリモーフィズムです。

三点セットで買っているもの

並べてみると、3つが同じ方向を向いていることが分かります。

• クラス — 扱いが変わっても、直す場所は1か所
• カプセル化 — 変更の影響が壁の内側で止まり、調査が要らない
• ポリモーフィズム — 種類が増えても、呼ぶ側は変わらない

#4で「オブジェクト指向が買っているのは変更に強さの一点」と書きましたが、その内訳がこの3つです。逆に言えば、一度動かして捨てるスクリプトに丁寧なクラス設計は要りません。道具には適用範囲があり、手段を目的にしないこと。ここはシリーズ第1回からずっと変わらないテーマです。

まとめ

• クラスは「データと扱いの約束を1か所に」。直す場所が散らばらない
• カプセル化は「知らなくていいこと」を壁で強制する。変更コストの正体である影響調査を消す
• ポリモーフィズムは「抽象に話しかけ、具体が各自応える」。追加しても呼ぶ側が変わらない
• 3つとも「変更に強い」に収束する。変更しないものには過剰

外伝はここまで。本編の次回は、シリーズ第1回から予告している「道具のパズル」——分解した課題に既製の道具をはめていく、アーキテクチャの話を書く予定です。