自分がどこら辺にいるのかはわからないが、知の4段階に譬えると意識的有能くらいの段階ではないかと思う。まだ何が良い設計なのか展望する眼はないようだが、そんな中でわかったようなことが少しずつ生まれていて、そのうちのいくつかはちょっと面白い考えが浮かぶ。

オブジェクト指向への短評

オブジェクト指向が考案された背景や、オブジェクト指向が得意なことはよく知られている。従来の手続き型パラダイムが持つ限界を打破するために、詳細には抽象的思考を保存し複雑なビジネスロジックを人が理解しやすい方法で自然に設計するために。しかしこの方法論がなぜ大きな支持を得たかは比較的扱われていない。そしてこれに関連して私が見つけた視点は二つ、事業と哲学である。

一。何かを責任持つ事業家、野心家は不確実性を嫌う。国境を接する北方帝国が朝鮮半島系国家を絶えず侵略した理由の一つは、大陸征服という事業を達成する前に後方を安定させるためだった。ローマはカルタゴを討つ前にイタリア半島を先に統一し、ドイツはフランス侵攻の前にソ連と不可侵条約を締結した。事例も動機も大きくは変わらない。事業の規模が大きいほど、責任者の執着が真剣であるほど、ブラックスワンの遮断は必須である。

二。現代物理学者が大統一理論を熱望すること、言語学者が世界のすべての言語の間に普遍文法があると仮定すること、経済学者が数百万人の行動を需要と供給という一つのグラフで説明しようとすることなどは、すべて雑駁さを統制しようとする意図からである。なぜそういう努力が歴史的に伴われてきたのか、その背後に認知コストを下げようとする実用的な理由もあるだろうが、私はアルベール・カミュの観点がより好きだ。例えば「人間は不確実性と曖昧さに耐えられず、明晰な認識観を希求するものだ」ということ。

ただ一度してみる想像に過ぎないが、直感としてはリスク管理気質のような人間本性としてオブジェクト指向を理解しても大きな違和感はなさそうだ。オブジェクト指向は伝統的な手続き型コードを分割して適材適所に整理し、その構造と名前に多くの道標を残す。その結果、複雑度と不確実性が統制され、開発者に安定感をもたらす。

SRP: 単一責任原則

オブジェクトはそれぞれ一つのみの責任を持つ。

似たように、文章作成には一つの文では一つの主題のみを扱うという一文一事の原則がある。なので単一責任原則の趣旨自体は馴染みがあり、誤解しやすい。「関心事を削って意味上の明快さを達成すること」、これはSRPの主な要旨ではあるが核心ではない。SRPが真に到達しようとする地点は、細かな意味の分岐を削ること、それによって変更の予測可能性を達成することである。

SOLID原則は生きて呼吸するプログラムを前提に作られた。状況は変わり続け、プログラムも変わり続けなければならない。この時に必要なのは孫子の兵法の態度、徹底した計算でリスクを管理し効率を達成しようとする算段である。有能な将軍は兵士を二度徴集せず、兵糧を三度輸送しない役不再籍、糧不三載という言葉の通り、反復コストを除去することは重要である。

同じ理由で、開発段階で作業目標を明確に認識することと作業量を最小化すること、副作用なく大胆に実行できることとそうでないことには大きなコスト差がある。この文脈で意味関係が明確であるということは、すなわち行動の波及力が予測可能であるということであり、これはすなわち行動リスクを計算できるということになる。SRPが一つの定石、基本と見なされる理由である。

DIP: 依存関係逆転原則

抽象が詳細に依存するのではなく、詳細が抽象に依存すべきである。

私は代替役として社会服務を履行しながら、会社の自己浄化能力がどこまで貫徹されるかを見ていたが、面白いことにその過程でDIP原則をずっと思い出していた。発想はこうだ。部署とその構成員間の業務分担がある典型的な会社構造で、DIPに従えば、会社は社会的に先に合意された概念、業務分担に対してのみ依存すべきで、その業務を遂行する従業員の個人技や技量に依存してはならない。

これは常識だ。会社の日々は固定されているように見え、昨日も今日も明日もその従業員がその場所で同じ業務を遂行するかのように感じられがちだ。しかし現実的に、定期発令や急激な人事異動、退職、極端にはバスファクターBus Factorでの恐ろしい仮定のように業務担当者が死亡するなどの理由で、従業員が交代することは起こりうる。もし組織が業務分担を超えて個人個人の能力にまで依存していたら、何らかの理由でその人が不在になった時に混乱が生じるだろう。

この観点で、一人の人に合意された範疇を超えた業務が委任される状況を防ぐべき理由は、それが一人の善意を利用する非倫理的行為だからである以前に、組織の持続可能性を脅かすからである。一度は大丈夫かもしれないが、複数回はダメだ。組織に要求される業務量が増えたなら、個人個人に業務を過重させるのではなく、業務分担を見直してでも責任分配構造を再編すべきである。そしてこの論理を技術的に翻訳すれば原文になる。「抽象が詳細に依存するのではなく、詳細が抽象に依存すべきである」

形骸化

実利的に提示された概念が一つの規範として定着するにつれ、意味は消え形式に変質する場合がある。実際、そういう場合があるどころか、私たちが知る大多数のものがそのように定着し、文化や伝統になる。OOPも実利に価値を置いた方法論として出発したが、今日のプログラミングカリキュラムにおいて一つの通過儀礼のように見なされる傾向は確かにあるようだ。

そこで疑問が湧く。すでに性能においてはDODという優れたアプローチがあり、状態管理の複雑性においては関数型パラダイムという代替がある。もちろんいつまでもこれ以上長寿する可能性もある。しかし最近のバイブコーディングからハーネスエンジニアリングまで、最近のトレンドはコード設計を人が直接覗かない方向に発展しており、今後もコードをオブジェクトとして書かなければならないのか疑問符がついている。どのパラダイムでも、いつまでも硬直した伝統として残ることのないように願う。