オブジェクト指向再燃（後編）
カルロ・ロヴェッリ著「時間は存在しない」を読んでみました。
著者は理論物理学者でループ量子重力論を提唱した方です。
「時間」というより「過去から未来に進む時の流れ」は存在しない、という内容です。
取り合えず読み終わることはできましたが、間違いなく正しく理解はしていないと思
います。しかし２点ほど、なるほどなぁ、と新たな気付きを得た感じがします。
ひとつは、物理学は物の変化を取り扱う学問であり、変化しない物は取り扱えない。
もう一つは、物の変化は他との相互の作用で生じるものであり、時間の流れで生じる
ものではない（時間は存在しない）。シュレーディンガーの猫のような量子力学の考
え方、相互作用が観測できない状況においては確率でしか取り扱えない、すなわち猫
が生死が重ね合わせの状態にある、という事象が少し納得できた感があります。
すこし語弊があるかも、というよりかなり強引なことをいうと、中編で書いた在庫管
理システムのモデル化の例、在庫の実在物そのものをオブジェクト化するモデルが何
故間違っているかというと、このオブジェクトに対して作用する（メッセージを送る）
モノが存在しないからです。変化は相互作用によって生じ、変化をしないモノは取り
扱えない、という理屈からしても、受け取るメッセージがないオブジェクトは変化を
生じないので取り扱うことができない、ということになります。
コンピュータの肝はCPUです。CPUはメモリ上に格納された命令列（プログラム）を
クロック信号と同期して、順番に読み込み実行していく装置です。そのため、原始的
なプログラミング言語程、命令型といって過去から未来に順番に処理を書いていく仕
様になっています。これって、過去から未来へ進む時間の流れの中で物の変化を取り
扱うニュートンの物理学に似ていると思いませんか？現にわかりやすく書かれたCPU
の解説書などはクロック信号と同期して、というくだりは省略して、命令を時系列に
処理していくという説明になっています。
時間と空間は普遍的だと考えていたニュートンに対して、アインシュタインは質量や
速度によって時間も空間も変化する、と考えました。山の頂上にいる人と地上にいる
人では速度が違うため時間の流れが違います。普遍的な時間の流れがあって、それが
物に変化を及ぼしていた、と思っていたのに、時間の流れ自体が変化するということ
がわかってきた。では、何が変化を起こすのかというと、それは相互作用ではないか、
ということでしょうか。CPUも時間の流れに沿ってで命令を処理しているわけではあ
りません。あくまでもクロック装置が出すクロック信号というメッセージを受取って、
命令を実行しています。そのため、同じ命令でもクロックが早くなればなるほど、同
じ一定の期間で処理される命令の数は多くなります。
オブジェクト指向の提唱者であるアラン・ケイはオブジェクト間でやり取りされるメ
ッセージ（相互作用）を重要視していたが、世の多くの人はクラスを重要視していた
と言う記事をみたことがあります。メッセージを介してのオブジェクトの相互作用を
パラダイムとしているオブジェクト指向は、物の変化は相互作用でおこる、とした新
しい物理の考え方によく似ています。だからオブジェクト指向プログラミングは正し
くて、命令型のプログラミングは間違っているのかというと、そうではありません。
それは相対論や量子力学が出てきたからっといって、ニュートン力学が間違っている
ということにはならないからです。事実、高校で習う物理はニュートン力学です。相
対論や量子理学は習いません。りんごの質量や落ちる速度で変化する時間や空間は微々
たるもので、ニュートン力学との誤差はどこにも何にも影響しません。しかし、GPS
システムにおける人工衛星の速度と時間の精度はでは、その誤差がシステムに影響す
るので、相対論による補正が必要になります。そう、GPSシステムの開発など、特殊
な世界を取り扱わない限り、世の中の普段の生活ではニュートン力学で充分なのです。
同じことがオブジェクト指向プログラミングと、命令型言語でのプログラミング
（あえてStaticプログラミングといってみる）の比較でも言えます。Staticプログラ
ミングでできることはオブジェクト指向プログラミングでもできます。どんな言語で
プログラミングしようと、最終的にはCPUへの命令に置き換わるのですから。りんご
の落下速度をプログラミングしたいのであればStaticプログラミングで充分です。オ
ブジェクト指向プログラミングだとより精度の高い結果が得られるかもしれませんが、
得られる精度の必要性と手間を天秤にかけると、もしかすると無駄な手間なのかもし
れません。しかしGPＳシステムのプログラミングとなると、Staticプログラミングで
は誤差が大きいので、手間をかけてでもオブジェクト指向プログラミンをしないとい
けません。たった、それだけの話。
そう、あの時Staticおじさんは、自分のやっている範疇だとオブジェクト指向まで必
要なくて、Staticプログラミングで充分！と言いました。それに対して、Staticプロ
グラミングなんて古すぎる。オブジェクト指向プログラミングをしろ、と周りが噛み
ついた。それは、Staticおじさんが、自分の必要としているところというドメインを
明確にしなかったため、一般論としてのオブジェクト指向否定論に読めたため。
当時、炎上しているコラムを見ながら、そんな風に感じておりました。炎上は些細な
行き違いが火種となるのでしょうね。
ようやく1０年来のモヤモヤを吐き出せて、スッキリしましたっ！
コメント
ちゃとらん
＞ あの時Staticおじさんは、自分のやっている範疇だとオブジェクト指向まで必要なくて、Staticプログラミングで充分！と言いました。
私も、そのように読めました。同意見です。
で、ついでに言うと、『中編で書いた在庫管理システムのモデル化の例』も、オブジェクト指向で設計、開発する必要性はないと思います。
さらに言うと、『ソフトウエア開発』においては、オブジェクト指向は不要とまで言い切っても良いと思っています。
では、私がオブジェクト指向言語で開発する理由はというと『保守』の為です。この『保守』には、時代に合わせたシステムの改修（改善とか機能アップ）を含み、これらをスムーズに行うには、オブジェクト指向言語による色々な仕掛けが必要だからです。
もう一つ、『受け取るメッセージがないオブジェクトは変化を生じないので取り扱うことができない』には、一応反論しておきます。私はあえて『変化しないオブジェクト＝イミュータブルなオブジェクト』を心がけて作っています。これはマルチタスクなどで取り扱うためには、必須だと思っています。あえて、ファクトリクラスやファクトリメソッド経由でオブジェクト（インターフェース）を返して、値を変更したい場合は、コピー生成するみたいな感じです。
これくらいでは、炎上しなさそうですね。
山無駄
どうも ちゃとらん さん
そうですね。それでもよいと思います。そういう趣旨のコラムでした。
因みに我々は、パケージ＋カスタマイズでビジネスをやっていますが、DevOpsではありませんが
開発と保守の境界は曖昧になってきました。お客と設計者とプログラマが膝詰めで話をしてゆき
ます。その際には共通のパラダイムを持つことと、各自が自分の領域だけで話をするのではあん
く、少しずつ相手の領域に踏み込む必要があります。そうなると開発だとか保守だとかという違
いはあまり意味がないものになります。
ちゃとらん
＞ パケージ＋カスタマイズでビジネス
…
＞ そうなると開発だとか保守だとかという違いはあまり意味がない
まったく、その通りです。（同感です）
先に上げた『開発』の言葉の定義は『作りっぱなし』という事なので、職業プログラマでの場合、まずありえないので、現在においては、オブジェクト指向は必須となるのでしょう。
＃ なので、staticおじさんの出番も、あまりないのでしょう。
とはいうものの、オブジェクト指向で作れば保守がしやすくなるのではなく、保守がしやすく作ることができる一つの方法として、オブジェクト指向言語がある・・・的な話なので、結局きちんと使いこなせなければ、ダメなんでしょうね。
なかなか、面白い題材でした。
山無駄
どうも ちゃとらん さん
よくいうIT業界の多重請負構造ビジネスの弊害か、最近システムを一から設計し、全体を見ながら開発し、保守運用
までを行って、まずい設計や作りをすると、その苦労がそのまま自分に降りかかってくる、という経験をしている技
術者がすくなっているのではないかと感じております。協力会社から来てもらった技術者が、一つの案件が終わると
そそくさと会社自体を辞めてしまう。そんな事象が最近続いています。話を聞くと、もともとこの業界から足を洗い
たくて、とは言うのですが、風のうわさで同業他社に就職活動をしている…。
おっと。この話は次のテーマで書こうとしてたのでした。
ちゃとらん
・・・・おおっと。
『作りっぱなし』システムが、あちこちに出来上がりつつあると・・・
＃ 一発物のなんちゃってオブジェクト指向プログラムは、某銀行系のCOBOLよりもたちが悪いのでは？
＞ おっと。この話は次のテーマで書こうとしてたのでした。
怖いもの見たさで、楽しみです。
sy
燃え上がりネタっぽいので投入しておきましょうか。こんなんじゃ燃えないか。
JavaScript/TypeScriptではReactというのが非常に流行っているのがご存知だと思うのですが
Reactではもうクラスベースのコンポーネントは使われずに
関数コンポーネントに多くの人が移行しています。
言語とライブラリの都合もいろいろありますが
あらゆるWebページを作ることを想定した複雑さがあったとしても
「オブジェクト指向」を使わなくても処理が行えることが
このあたりのプログラムを日々書いている人にはもう常識となっています。
フックの導入 – React
https://ja.reactjs.org/docs/hooks-intro.html#classes-confuse-both-people-and-machines
自分も以前は「オブジェクト指向」大事、と思っていましたが
ReactやJSを使っていていろいろ気付かされたので
オブジェクト指向は使わないで処理を書くほうが楽だなと感じるようになってしまいました。
それらの3大原則とか3大要素とか言われる
「継承」「カプセル化」「ポリモーフィズム」
これらは今後も積極的に使わない方がシンプルなコードになると理解しているので使わないです。
下記のリンクなどもすでに読まれているかもしれませんが
読者の方は知らない方も多いかと思いますので示しておきます。
気分はstatic！「実はオブジェクト指向ってしっくりこないんです！？」という記事に「staticおじさん達に伝えたい…」とオブジェクト指向擁護者が反発しバカにしていましたが、不当ではなかったですか？ - Quora
https://qr.ae/pGBSGu
オブジェクト指向プログラミング -- 1兆ドル規模の大失敗 という記事があります。そうなんでしょうか？ - Quora
https://qr.ae/pGlruf
オブジェクト指向のプログラムは難しいと言われる理由は何ですか？クラスごとに纏まっていて見やすいように思えますに対する回答 - Quora
https://qr.ae/pvCFIZ
山無駄
どうも ちゃとらん さん
そう。一発ものや、オブジェクト指向に関わらず、なんちゃってシステムの乱造はIT業界の
ガンではないかと。
山無駄
どうも sy さん
そうですね。燃えないでしょう。紹介してもらったような内容はおおよそ燃え尽きてしまったかなと
感じたので、今回のシリーズを書いております。
本来のオブジェクト指向のパラダイムを理解したうえで、今回つくるソフトウェアに必要であれば適
用すればよいし、必要ないのであれば適用しなければよいだけ話です。そういった意味では、元祖Static
おじさんは気の毒？な面もあると思います。自分が作るプログラムにはオブジェクト指向は必要ない、
と言っているだけなのに、オブジェクト指向そのものを否定された、と思った人たちから叩かれてし
まった。じゃあだからと言って、件の大炎上はやはりオブジェクト指向原理主義者？の所為なのか、
というとそうでもない。オブジェクト指向原理主義者の人とたちは、なんとかStaticおじさんを説得し
ようと、あの手この手で説明を試みてます。たかだかブログのコメント欄に、そこまで書くか、という
ぐらい。残念ながら玉石混交なので使い物にはなりませんが、秀逸なコメントを集めればもしかする
と立派な教科書ができるかもしれません。一方でStaticおじさんは、多勢に無勢の中を戦い抜くバイタ
リティには感心するものはありますが、だからと言って説得や説明を理解する努力をしているように
は見えない。だんだん反論も的外れになって来て、さらに炎上。でもそれは仕方いと思います。Static
おじさんは自分でも書いているように、オブジェクト指向を適用する必要がないのですから。
この状況を傍から見た人が、Staticおじさんを、新しい技術を学ぶ努力をせず、頑迷に拒否する老害技
術者とイメージ化してしまったのではないかと思います。あくまで個人的な解釈ですが。
例えば、syさんは「継承」「カプセル化」「ポリモーフィズム」 は使わない方がコードがシンプルに
なるから、使わないと書かれています。それは、そうです。コードの観点からすると余計な機能は使
わない方がシンプルになるのは当たり前で、一般論としてコードはシンプルな方が良い。とされてい
ます。しかし一方で作るものの要件によっては、コードのシンプル性よりも「継承」などを使わない
いけないものもある、ということは理解されるのではないでしょうか。事実、コンピュータの歴史か
ら考えると「継承」「カプセル化」「ポリモーフィズム」の考えや機能は、その必要性があったから
こそ考え出せれています。
この様に、自分がオブジェクト指向を使わない、使わなくなった、使ったことがない、ということは
オブジェクト指向が間違っている、という証拠にはなりません。また何を作ろうとしているから、と
いいう前提がないままで、何を作るにしても使わない、ということは、それは何もかもオブジェクト
指向と主張する原理主義者と何も変わらない、ということだと思います。