「ポチ」が鳴いても、システムは動かないーー00年代、オブジェクト指向入門の迷宮

先日「生成AI時代に問う、プログラミング教育の意義」の中で、00年代後半のオブジェクト指向プログラミングについて少し触れました。

今にして思えば、あの当時のオブジェクト指向入門書籍や各種の説明記事は、結構ヒドかった思い出があります。

今回は、冒頭記事のスピンオフ。あの頃の「モヤモヤ」について振り返ってみます。
私と同様に00年代にオブジェクト指向プログラミングを嗜んでいたエンジニア諸兄姉には、懐かしい内容になっていると思います。

逆に私は“現代のオブジェクト指向”がよくわかっていないので、まさにいまオブジェクト指向を学んでいる方々からのリアクションもお待ちしています。

1. 楽園の住人、犬のポチ

当時の入門書を読んだ方は大抵、犬のポチに出会ったのではないでしょうか。

だいたいが、こんな説明で溢れていたような気がします。
なんと平和な説明でしょう。と同時に『だから、何？』という心の声が止まりませんｗ

業務システムでの開発はどうするの？
自分が作っているのが購買管理システムだとして、注文データのインスタンスは、いつ、何に向かって「鳴く」のでしょうか。。

犬クラスの説明自体がグダグダだなと思うのですが、これは、呼ばれる側の振る舞いの話に終始していて、呼ぶ側の論理が欠如しているが故に混乱が深まったのかな、と思います。

2. 「料理人」という名の迷宮

他にも、ポリモーフィズムの説明ではこんな記載があったような記憶があります。

「料理人クラスに『作れ』と命じると、材料が肉ならステーキになり、魚なら焼き魚になります」。

またしても、だから、何？です。
「……それって、料理人クラスの内部で if (material == Material.MEAT) と分岐させてるだけじゃないの？ 肉や魚をクラスに分ける意味、どこにあるの？」ですよ。

本来、ポリモーフィズムのうまみは「食べる人(呼び出す側)」にあります。食べる人は「食べる」という命令を出すだけで、目の前に出てきたものがカレーかフレンチか気にしなくていい。新しい料理(クラス)が増えても、食べる人のコードは1文字も書き換えなくていい。
(入門書の喩えに無理やり乗っかってみましたが、やはりわかりにくいですね...)

それがどれほどありがたいことか——は、実際に「料理の種類が20種類に増えた時」という仕様変更を食らってから、ようやくわかるのです。

振る舞いの違いという呼ばれる側の特性より、変更に強い呼び出し側を設計できることこそが、ポリモーフィズムの真髄だと思います。

3. 棟梁のいない工事現場

一番のモヤモヤは「メッセージパッシング」でした。

「オブジェクトたちが互いにメッセージを送り合い、自律的に処理が進みます」。

文字通りに受け取れば、それはもはや魔法です。そんなわけがない。
注文オブジェクトに「確定しろ」とメッセージを送れば、あとは勝手に在庫や配送のオブジェクトとやり取りしてくれる——みたいな、あり得ない話です。

「在庫が切れていたとき、DBトランザクションをロールバックさせる指示は誰が出すんだ！」という叫びが聞こえてきそうです。というか、私が発したくなりましたｗ

棟梁(全体を束ねる役割)のいない工事現場で、大工と左官がメッセージを送り合っても、家は建ちません。当時の本はなぜか「全体を統制する司令塔」の存在を「美しくない」とでもいうように、きれいにスルーしていた気がします。

結局、誰かが胃を痛めながら全オブジェクトに指示を出し、例外が発生すれば「誰の責任だ！」とログを吐き散らす。そんな泥臭さが、現実のプログラムには表現されるんです。

組織でもプログラムでも、現実で必要なのは、自律分散の幻想より、統制と責任の所在ですからね。

4. 基底クラスに実装するのは「最大公約数」ではなく「不変」

当時の入門書は「犬は動物である（Dog is-a Animal）」というような、分類学でオブジェクト指向を捉えていました。

でも、現実のシステム設計で大事なのは分類ではなく、「不変なもの」の見極めなんですよね。

「犬も猫も鳴くから、基底クラスに 鳴く() をまとめよう」

これは最大公約数の思考です。
ウサギやアメーバが仲間に加わった途端、その設計は崩れ始める。鳴かないウサギのためのSay() や、歩かないアメーバのための Walk() を空のメソッドで実装するというパッチワークが始まり、クラスと継承の構造が崩れていきます。

これが「継承は強力過ぎる」と言われた所以であり、クラス＋継承のオブジェクト指向が絶対正義ではなくなっていった大きな理由なのではないかと思います。

私も、自分自身で試行錯誤(とoverride)を繰り返すうちに、この考え方が根本的に間違っていることに徐々に気づいていきました。

本当に基底クラスに置くべきは、最大公約数ではなく「どんな派生クラスが来ようとも変わらない不変のロジック」なんですよね。

『このクラスを使う以上、この処理は誰が使っても同じ振る舞いを期待する』。
基底クラスで実装するのはこういった処理だけにして、『最大公約数』は、処理をなるべく小さく区切って仮想メソッドで提供する、というのが、当時私がたどりついた結論でした。

このあたりの実例は、冒頭で紹介した過去記事でも触れていますので、もしよろしければ読んでみてください。

おわりに

本記事で触れた犬クラスや料理人の喩えの他にも、「テレビの内部構造を知らなくても、リモコンで操作できればいいよね？」なんていう、カプセル化の説明も懐かしいです。

今思うと、この説明をしていた人たち、本当にオブジェクト指向を理解していたのでしょうかｗ
百歩譲って「入門編だから」と割り切っても、次のステップへ進む足がかりにはなりにくかったように思います。

ただ、AIが完璧なコードを一瞬で出してくれる現代では、あのモヤモヤと向き合う時間はなかなか生まれにくいかもしれません。

「何かが違う」という違和感を一つずつ解いていったプロセスが、私の中でのオブジェクト指向の1つの形となり、今も違った形で活かされているのですから、あの試行錯誤は遠回りではなかったのかな、と思っています。

オブジェクト指向そのものは、昨今もはやテクノロジーやプログラミング言語に溶け込みました。
が、その根底にある考え方は、今でも通じる「思考のOS」になると思います。

ひとまず、今はもうポチが鳴いていることはないと信じたいですねｗ