オブジェクト指向は失敗だった

オブジェクト指向プログラミングは失敗だった――以前から思っていました。

okuranagaimo.blogspot.com

オブジェクト指向プログラミング (OOP) が人類にとって早すぎたか、人類には OOP が向いていなかった。世の中の Java で作られたプログラムのほとんどは、Java に付属する OOP っぽい機能を使うことで余計に複雑になっているように思います。ここでいう複雑さとは、頭が整理されていない状態、頭が構造化されていない状態のことです。例えば、インスタンスなんて作らずに全部 static メソッドでベタ書きされた方がよっぽどわかりやすいのに、それができてしまうからという理由で要らぬ副作用、すなわちオブジェクトの状態の変化が入りこんで、おかしなことになっている様子に出会ったことは何度となくあります。

おそらく原始的で単純な OOP で作られたプログラムはそこまで問題ではない。データ構造があって、その操作がメソッドになっている―― 例えば toString() みたいなデータ構造を変換する操作をデータ構造に集めることはおかしなことではなくて、toString() みたいな共通化された I/F が問題をシンプルにするのは疑いようのないことだと思います。そのデータ構造を文字列化したものが欲しいときに、toString() メソッドを呼ぶだけで済んだら、話は簡単になりませんか。

問題はそもそもデータ構造だけでは世界は表現できないことと、「継承」という要らぬものが導入されたことだと思います。

オブジェクト指向プログラミングでは、現実世界の森羅万象をプログラムに表現できるなんて言説をどこかでみたことがあります。しかし、それは無理です。クラスという表現の形式は、現実世界をモデル化するには十分な表現力をもっていない。そもそもプログラムとは何かを「する」ためにあるものです。何かをすることを私たちはしばしば処理といいますが、処理すらクラスで表現すると難しくなります。

ただのサブルーチン（関数）だけの方がクラスよりよっぽど処理の表現として優れています。処理をクラスで表現しようとするから、-er みたいな名前のクラスができて、処理だけするクラスの中にフィールド変数が現れて、処理の中でそれを触ったりすることが行われる。単一責任の原則にしたがって、1個の処理だけする -er みたいなクラスとは、要するに関数オブジェクトです。こんなもの作るなら、ただの関数の方がよい。

継承も同じことで、処理をする部品（メソッド）を共有したかったら、関数を別に切り出して共有すればいいだけだ。クラスである必要がない。また、階層構造のモデルで、問題を表現しきるのが難しいというのはリレーショナルデータベースを使ってたら知っているはずなのに、どうしてオブジェクトの関係を階層構造で表現したいと思うのでしょう。継承なんていらない。処理だけ欲しければ関数の方がいい。

動的に処理を切り替えたければ関数を切り替えればよい。デザインパターンっぽいものは、要するに処理を関数オブジェクト化してクラスとして切り出したら、切り替えられて便利だよねってだけのはなしです。つまり、出来の悪い関数プログラミングです。関数を値として渡せたらそれで十分だ。でも、それも下手に使われるよりはベタ書きの方がずっといい。

処理と呼ぶものは関数で事足りる。クラスはデータ型とその操作のための I/F としての役割で十分だ。

プログラミングというのはただやりたいことを順序立てて書くだけのもので、それ以外のことを考えないようにしたい。処理をオブジェクトで表現するにはどうしたらよいのだろうとか共通化するにはどうしたらよいのだろうなんて無駄なことを考えなければならない OOP は、不完全な枠組みだったと思います。

static メソッドでよいのでは？

static おじさんと呼ばれる人がいたそうだ、あるいはいるそうです。インスタンスの生成を嫌がって、何でも static メソッド にしてしまう人のことです。static メソッドと呼ぶよりも関数と呼んだ方がよいかもしれません。

インスタンスの生成を嫌がるのは、気持ちはわかります。メモリ管理が GC 任せで、速度にどう影響するかわからないのが嫌なのでしょう。現在では、細かいメモリ管理が本当に必要な場合はほとんどないので、ほとんどの場合インスタンスの生成なんて無視してよいでしょう。しかし、ひとつひとつの処理に対してコスト感覚を持つこと自体はよいことです。問題があるとすれば、その感覚が誤っていることでしょう。

ただ、おそらく static おじさんと嘲笑されたのは、コスト感覚の誤りからよりも、未知のものがわからない、覚える気がない態度からでしょう。いつか私も Java おじさんとか Linux おじさんとか言われるのかなと思うと、笑ってられません。

でも、static おじさんがどうだとか言っていた人は、本当にオブジェクト指向を分かっていたのかと疑問に思ったりもします。

役割駆動設計で巨大クラスを爆殺する - Qiita

この記事にある、コンテキストに対応する役割を振る舞うのに必要な最小限のフィールド、メソッドが定義された動名詞のクラスとは、関数オブジェクトのことではないでしょうか？関数オブジェクトとは、関数をオブジェクトにしたもので、引数に渡したりできる関数のことです。SOLID 原則の最初の一つ「Single Responsibility Principle 単一責任原則」に従っていくとクラスは、ただの関数オブジェクトになってしまうと思います。『Clean Architecture』の単一責任原則の章には下の絵が書いていました。たった一つの仕事しかしない 〇〇er は、〇〇関数と変わりありません。

関数オブジェクトであれば、わざわざオブジェクトにしなくても、static メソッドでほとんど同じことが表現できます。むしろ static メソッドを使った方が、記法としてシンプルです。引用元の記事を書いた人も、Robert Martin も、static おじさん叩きなんてしてないことは念のためいっておきますが、オブジェクト指向を分かっていると思われる彼らが一周回ってたどり着いたのは、static メソッドと同じものではないでしょうか？

関数オブジェクトだと、引数に値として渡したりできる利点はありますが、コールバック関数をむやみに使う設計はあまりよい設計とは言えません。業務モデルにはほとんど使わないでしょう。また、Java 8 からは static メソッドであっても、値として渡せます。 だったら、もう関数オブジェクトを作らずに、static メソッドでよい。

データ型の表現には、インスタンスを作るクラスを引き続き使う必要があります。しかし、手続きを表現するには static メソッドでよいのです。つまり、static おじさんが正しかったのです。

具体的すぎてわからない

具体化という言葉を会社員をしていますとよく聞きます。特に企画の仕事では良く耳にします。再建策に具体性がないみたいな批判も経済ニュースではよく見ます。どうも、具体的なのは良きことで、抽象的なことは悪しきことみたいです。具体化していくのが仕事だ！といった話もしばしば聞きます。

それは間違ってはいないでしょう。抽象概念に金を払う人はいないですから、仕事でやっている以上何かしらの実体にせざる得ません。抽象概念を操っているように思える数学者でさえ、紙に書かれたものにしなければ仕事とは認められません。

仕事ならば、放っておいても勝手に話を具体化し始めます。すぐにタスクのブレークダウンを始めるし、気の早い人だったら何か「成果物」をつくり始めます。何か不安なのか、取り憑かれたように具体化が行われます。具体化とは難しくないし、それで仕事が進んでいるように見えるからでしょう。

しかし、急速に具体化が進むのは必ずしも正しいとは思わない。具体的な何かが出てきたら、枝葉末節のどうでもいい議論が始まりませんか。そもそもの目的が妥当なのかだとかを決着せずに、各論を議論して何の意味があるのでしょう。また、急に具体的な話が出てきても、何の話をしているのかさっぱりわからないのは、私だけでしょうか。

目的が不在なのは失敗プロジェクトの典型です。具体化――仕事を進めるのは、作業者が仕事をしているフリをするためにしているもので、それは仕事であって仕事でない。まして、仕事でない仕事を見て満足しているのは、マネジメントの仕事でない。

すぐに各論に飛びついて具体化を急ぐよりも、抽象的な状態で話を整理しながら、少しずつ抽象度を下げていった方がよいと思う。

イメージとしては、金属の焼きなましです。 *1 金属は急激に冷却すると、内部の組織に結晶ができて固くなるが、それぞれの結晶は勝手気ままに結晶化しているので、全体としてはひずみができます。焼きなましとは、ゆっくり金属を冷却して、ひずみがない材質をつくる方法です。各論に飛びついてすぐに具体化が始まって、全体としての整合性がない状態と焼入れは似てませんか。これを防ぎたかったら、具体化したいという欲望を抑えてゆっくり抽象度を下げていくべきでしょう。あるいは、具体化が急すぎると感じたら、手もどりをさせるか。手もどりは、焼もどしに似てますね。

抽象度を自在に移動して、適当な抽象度で議論をするのは、高度な知性で、習得したいとは私も思ってますが、なかなか困難です。それでもあえてコツをあげますと、抽象度が高いのとぼんやりふんわりしているのは違うので、抽象的であってもフォーマルに言語化をしてその抽象度でのあいまいさはないようにすることでしょう。例として適当かあやしいのものの、例えば数式モデルはいろんなものを取っ払って抽象化されていても、それ自体はよく定義されたあいまいさのないものです。具体化と同じぐらい明確化というのを企業ではよく耳にしますが、抽象も明確化はできて、そうしろと言っているのでしょう。

具体化は人間の思考のくせみたいなものであいまいなものでも自然と具体化は進みますが、抽象度を保ったまま言語化するのは頭に負担がかかる疲れる仕事です。それでも、ここを踏ん張って行うのが大事なのかなと思います。それができたら、抽象度を落としても、具体的な議論であってもどうでもいいということにはならないはずです。

*1:焼きなまし法 - Wikipedia

結合の種類と結合度

先日に発見したモジュールの結合の定義を自身でも気に入ったので、よく知られている結合の種類をこの定義に当てはめてみようと思います。

• Coupling (computer programming) - Wikipedia

モジュールの結合にはいくつかの種類がありまして、以下のものが知られています。

• 内部結合 content coupling
• 共通結合 common coupling
• 外部結合 external coupling
• 制御結合 control coupling
• スタンプ結合 stamp coupling (data-structured coupling)
• データ結合 data coupling

名前が変だし、それぞれの関係性も分かりづらいので、この分類はあまり好きではないのですが、他のもっと良い分類をしらないので、とりあえずこれを使います。

モジュール の モジュール に対する結合度 を以下の式で定義します。

ここで、 は が に対して持つ仮定の集合、 は仮定 が成立しなくなる確率です。

それぞれの結合の種類が、この結合度の値にどう影響するのか考察していきましょう。

内部結合 content coupling

あるモジュールと別のモジュールは、普通はインターフェースによって接しています。Java の interface だけでなくて、関数やクラス/メソッドといった、インターフェースを定義して外部に公開できる機能がプログラミング言語には用意されています。普通の人は、この機能を使って他のモジュールと自身のモジュールを結合させます。

しかし、インターフェースという概念すら理解していない人は、それを無視して、リフレクションで private な変数を取ってきて、使ったりします。こういう他のモジュールの内部に結合するような種類を内部結合と呼びます。

インターフェースは変更をすれば、呼び出し側も変更しなければならないので、あまり頻繁に変更しようとは思いません。しかし、内部は仕事をしていれば変更されます。モジュールの内部が変更されないという仮定は高い確率で成立しなくなるので、モジュール間の結合度 C は非常に大きくなります。

プログラミング言語の機能で普通すればできないようになっているので、意図して汚く脆弱に作ろうとでもしないかぎり、内部結合をつくってしまうことはないと思いますが、決してそんなことはしてはいけません。

共通結合 common coupling

いわゆるグローバル変数を共有している状態です。グローバル変数を使うときは、他のモジュールがこちらの意図どおりにグローバル変数を書き換えている/いないことを仮定しています。この仮定は壊れやすいので、グローバル変数を共有しているモジュールの結合度は高いです。

もし、グローバル変数が immutable であれば、意図しない書き換えが起こる可能性は低いので、疎結合は保たれます。例えば、設定変数はグローバルに持っていてもよいでしょう。

外部結合 external coupling

２つのモジュールが、ファイルやプロトコルといったもので結合している状態です。モジュールというかシステム/サービスの結合の話のようです。これだけ毛色が異なります。

なお、出典によって、例えば 『ずっと受けたかったソフトウェア設計の授業 』と wikipedia 、意味が違うのですが、wikipedia の方を採用しました。原典に当たるほどでもないし、正しいとかないので。

制御結合 control coupling

あるモジュールが他のモジュールの動きを制御している状態です。例えば、クラスに○○モードみたいな名前の変数があって、それを変えると動きが変わるような場合です。

制御する方は制御される方がどう動くのか知りすぎた状態になるので、この２つのモジュールの結合度はやや高くなります。抽象化が十分でなくて、中身が漏れているイメージですね。制御用の変数が増えて、変な if 文が追加されていきそうなのが、想像できます。この場合は、制御する方もされる方も不安定な I/F に依存していることになります。

インターフェースを抽象化して、ポリモーフィズムなどを使って、知り過ぎない状態にするのが解決方法です。

スタンプ結合 stamp coupling (data-structured coupling)

なぜスタンプなのかはよく分かりません。データ構造で結合している状態とは、引数や返り値に独自に定義したクラスなどを使って、それで２つのモジュールが通信している状態などです。必ずしも悪いわけではないが、不必要な型で結合するのは、要らない仮定を持ち込むことになります。仮定の数が多ければ結合度が高まります。

１つのフィールドしか要らないのに、データ構造を丸々渡してしまうのは、良くないでしょう。例えば、 this を引数に渡すのは乱暴さを感じませんか？

また、引数には複数の値が渡せますし、返り値としても Python などは多値を返せます。意味もなく型を共有せずに、基本的な型だけのインターフェースの方が、使いやすくなることもあるということは知っておいた方がよいでしょう。

データ結合 data coupling

必要なデータだけを交換して結合している状態です。要らない仮定がなくて、仕様が安定している状態なので、結合度が低いです。

モジュールの分割点

アーキテクチャの問題とは、システムをどこで分割 (decomposition) するかという問題と言い換えてよいでしょう。分割するのは、魚を捌くのと同じようなもので、包丁を入れるべき場所というのがあります。

分割するというからには、切り分けるサイズがありますが、今回は分割の単位の議論はしません。なぜかといいますと、ちゃんとつくれば、システムの部品は入れ子構造になっているはずです。再帰的に作られているという言い方もできます。つまり、システムを切り分けて出てきたものは、やはり同じやり方で切り分けることができます。マトリョーシカというか、フラクタル的といいますか、問題を切り分ければ同じものが出てくるはずです。明らかに正しいことが分かるサイズが最小単位で、そこに至るまで分割を繰り返されたものが、ちゃんとした仕事でしょう。

問題をバラすときにタテに切るかヨコに切るか、そしてその切り目はどこかというのは、分割のサイズに依らず決まっているように思います。まだ全てを発見したわけではないし、重複もあるかもしれないということを断った上で、以下を挙げます。

• データ構造
• トランザクション
• 共通機能
• 組織
• 開発の時系列

データ構造

特にクラスベースのオブジェクト指向プログラミングではデータ構造でモジュールを分割するのが基本でしょう。データを統べることが機能であり責務であるというところから、データ構造とデータの操作を切り出してまとめたのがクラスです。人間が計算機にさせたいことは、データの変換と記録だけなので、データから考える方が簡単です。人間の興味とシステムのアーキテクチャが一致していたら、扱いやすいものができるそうなことは想像がつくでしょう。

トランザクション

システムのアーキテクチャは人の興味に一致していた方が便利である――というのは経験則であります。データ構造からたどる方が一般にやりやすいと思いますが、システムにやらせたいこともシステムの切り目です。WEB システムに API が複数生えていたら、当然 API ごとにモジュールを切り分けますよね？やらせたいことは、トランザクション/手続きといった方が分かりやすいかもしれませんが、それらごとにモジュールは分割されます。クラスの中もメソッドが分かれております。これもデータ構造に対してやらせたいことごとに分割されているはずです。

共通機能

同じシステムは一つとないとはいっても、だいたいどんなシステムも似たようなものでして、全く同じ機能がいることが多々あります。そういうものは共有できるように別モジュールに切り出した方が便利です。ライブラリとかフレームワークとか呼ばれたりします。ただし、意味もなく再利用を志向するのは避けるべきです。そういうのが再利用されることはまずありません。

レイヤードアーキテクチャは共通機能で分割する手法の一種です。分解して抽象度を落としていくと、同じものが必要になります。自然界だって要素に分解していくと、原子・素粒子と全てが同じになります。同じものはみんなで共有して使いまわした方が便利です。

組織

コンウェイの法則で知られるものです。組織が異なったらモジュールも分かれます。人が異なってもモジュールは分かれます。組織が巨大化しているのに、モノリシックなアーキテクチャを維持するのは無理です。組織を編成するひとは、アーキテクチャを知って仕事をしないと、組織は上手く回らないでしょう。

開発の時系列

後から機能を加えるときは、取ってつけたように追加せざるをえません。組織でモジュールが分かれるように、たとえ同じ人がやっていたとしてもプロジェクトの単位でモジュールが分かれるでしょう。開発プロジェクトは何かしらの論理的な単位で切られるものなので、そこでモジュールが分かれるのは不自然ではないでしょう。むしろ、既存のモジュールに変な条件文を加えるほうが、不自然な改修だと思います。

メソッドは関数ではないのだが

Clean Architecture を読んでいて、クラスおよびメソッドのことを、関数あるいはサブルーチンの一種としているような記述があって、やや気に障りました。

具体的には、単一責任原則の説明のところでして、

上の絵のように Employee というクラスにいろんな機能を集めたら、太っちょになります。

そのため、このように機能を切り出したらよいでしょうとあります。

最初に巨大化するようなクラスを定義してしまったら、こういう関数っぽいクラスに切り分けるのも仕方ないことと思います。しかし、この設計がきれいとは思えないです。手続きを頑張ってクラスの中に書いたら、余計に汚くなるように思います。世の中そんな仕事ばかりです。

普通のオブジェクトは手続きよりも、むしろデータ構造を記述するものです。普通に作ったら、欲しいデータごとにクラスがあって、それらに対する操作するがメソッドになるはずです。多分以下みたいになるのではなかろうか。

なお、本には Clean Architecture といって、ドメインモデルが定義された設計についても、ちゃんと書いていることは補足しておきます。

疎結合の正体見たり

モジュールが疎結合になっているとか密結合になっているとか、業界にいますとよく聞きます。モジュール間の結合度の定義を発見したのでメモしておきます。

モジュール の モジュール に対する結合度 は以下の式で定義できます。

ここで、 は が に対して持つ仮定の集合、 は仮定 が成立しなくなる確率です。

要するに、これは情報エントロピーを用いて結合度を定義しようとしていまして、 は0以上の値を取り、結合度の値が大きいほどモジュール間の結合が密となります。

そもそも、モジュール間の結合度というものが定義されていなかったので、その定義を発見したことに意味があります。

さらに、この定義が便利なのは有名な設計原則を説明できてしまうことです。以下のようなものを聞いたことがあると思います。

• デルメル原則
• リスコフの置換原則
• ハリウッド原則
• 驚き最小の原則

これらはだいたい同じことを言っています。依存する側が持つべき仮定のことを仕様といいまして、依存する側はできるだけ少なく、覆ることがなさそうな仮定の上でシステムを作れと言っています。結合度 C は、仮定の数が少なく、仮定が成立し続ける蓋然性が高いほど、小さくなります。

簡単のために原則でない例から挙げていきますと、REST API でシステム間を疎結合にしたマイクロサービスとか良くいいますよね。API 仕様が安定で、HTTP プロトコルが廃れる可能性が低ければ、結合度 C は小さくなります。逆に、システム間で、データベースやソースコードを共有していたりすると、それらが変わる可能性は高いので、C が大きく密結合になります。

他にも、Java の標準ライブラリに密結合しているとは誰も言わないのは、Java はサービスの寿命が続く限り使い続けることができて、Java の標準ライブラリは安定していて変わる心配をする必要がないからです。一方で、 Kotlin が廃れる可能性は高いので、Kotlin で作ったアプリは Kotlin と密結合だと言ってよいでしょう。

原則に戻りますと、デルメル原則は別名で最小知識の原則といいまして、結合度 C の定義でいうところの、仮定の数を少なくしましょうという法則です。仮定の数が少なければそれだけ疎結合になります。

リスコフの置換原則・ハリウッド原則についても、これらはインターフェース仕様にのみ依存して、実装が変わっても動くように作れといっています。インターフェース仕様は安定していて、変わる可能性は低いので、 P が小さくなり、疎結合が実現できます。一方で、不安定なインターフェース仕様だと、余計に密結合になってしまうでしょう。

驚き最小の原則も、要するにびっくりしない仕様は普通の仕様なので、安定しているから、それに依存すれば疎結合だよねという意味です。

他の例を上げれば、バグがあって、バグを回避するように奇妙な細工をしたら、バグを改修された動かなくなります。バグが直らないという不確かな仮定の上に作られているので、結合度は大きいです。あるいは、他のライブラリの private な変数をリフレクションで覗いて、それにロジックに組み込むという正気を疑うコードを昔見たことがあります。当然のように相手のバージョンが上がったら動かなくなってましたが、これも不確かな仮定の上に作られた密結合な作りです。

設計を評価するのに、今回発見した結合度の定義は大変有用性が高いように思います。