「データと振る舞いの一体化」と擬人化の弊害

最近 Functional Programming for the Dysfunctional という、面白い関数型プログラミングの紹介記事を読んだ。

序盤あたりに OOP と FP の対比があるが、ざっと要約すると下のようになる。

OOPは WHAT=データ, HOW=振る舞い, WHEN=時間を編み合わせて新たな複雑性を生み出してしまうが、逆に FPはこれらを分離してシンプルにする。

この説によれば、よく言われるような OOP と FP との直交性どころか、二つは相反する真逆のアプローチってことになるけど、オブジェクト指向から純粋関数型に移ってきた人なら、結構、実感としてわかるんじゃないだろうか。

さらに OOP に着目して少し敷衍すると、低結合・高凝集を目指してたはずの OOP 自らが、結合度を高め、凝集性を低める元凶になってしまっているとも言えないこともない。OOPやってた頃は考えもしなかったが、少なくとも今はそのように理解している。

ところで、ここで二つの疑問が湧いてくる。一つは、どうしてデータと振る舞いの一体化なんて愚行が、OOPの現場で未だに行われ続けてるのだろうって疑問（発祥はともかく）。もう一つは、どうしてこの手法の拙さが推奨されたまま疑問視されないのかって疑問。

■ なぜデータと振る舞いの一体化を止めないか

Simple Made Easy という、Clojure の開発者 Rich Hickey 氏が Simple と Easy の違いを解説した有名なプレゼンがあるが、その中で OOP では Simple と Easy を混同した挙句、初期のハードルが高めの Simple を避けて Easy に走ってしまいがちなことが詳説されている。

つまり「データと振る舞いを一体化」も、例のごとくOOP技術者が易きに流れてるだけって話ではないだろうか。OOP界隈では DB と HTTP の間の全てを巨大な手続きに混ぜ込んだトランザクションスクリプトがよく批判されるけど、OOP自身もせいぜい「データと振る舞いの一体化」に留まった中途半端なレベルから出ていなかったのではないかと。

実際に、そのレベルから脱却した純粋関数型DDD の近年の発展を見ていると、そのように思えてしまう。

■ なぜデータと振る舞いの一体化に疑問を持たないのか

最初に紹介した記事では、OOP と anthropomorphized=擬人化の関連も指摘されている。この擬人化には、協働（collaborationDictionary）と共に責務（responsibility）も含まれるけど、OOP界隈ではこれが特に重視されている。

まあ「どこに何を置くか」考えるのは大事だし、それを主体性や自意識をもった何かのごとく責務と呼ぶことは別に良しとしよう。

ただ困ったことに、これが神聖視されすぎたまま魔法のワードというか免罪符になってしまって、それでデータと振る舞いの一体化なんてよく考えたら変なことまでも、なんか責務！って言っちゃうとそれで正しいような錯覚が生まれてしまうのではなかろうかと思う。


まあ自分も、キャリアの大半をオブジェクト指向でやってきたので、ついつい責務って言葉を頻用してしまうけど、関数型プログラミングの現場だとやっぱそろそろ控えた方が良いかもしれない。恥ずかしいしな。