■オブジェクト指向 v.s. 関数型プログラミング

近年、関数型プログラミングの重要性はいろんなところで叫ばれています。

Javaの最新バージョンに関数型プログラミングに関する新機能が加わりました。

Rubyも昨今、関数型プログラミングへのサポートが手厚くなってきています。

プログラミングの教科書の大手、オライリー社から、Javascriptで関数型プログラミングを行うための解説書が発行されました。

関数型プログラミングへの注目度は高まってきています。

おそらく、みなさんは既にオブジェクト指向が何か、を知っています。

でも関数型プログラミングとは何か、胸を張って語れる人は、周りに見当たらないかと思います。

実際、オブジェクト指向によってプログラミングする方法は、わかりやすい解説があちこちにある一方で、

関数型プログラミングとは何か、何が良いのか、ということについての、よいまとめは見つけることはできませんでした。

この記事を読む方の中で、「関数型プログラミングを取り入れるか・取り入れないか」で切実に悩んでいる人は、おそらくいないでしょう。

この記事はあまり細かいところに立ち入りません。関数型プログラミングを使う側の立場に立って、利点や向き・不向き、それが導くスタイルを書きました。

みなさんは鳥のように飛んで、高い空から、関数型プログラミングとは何か、何が良いのか、を見渡してください。

ふたつのアプローチの比較

オブジェクト指向的アプローチは、名前をつけてプログラムを整理する。

関数型プログラミング的アプローチは、汎用部品でなんとかする。

オブジェクト指向的アプローチ

Googleが近年リリースした言語、Goには、”継承”を直接サポートする仕組みが無いことが話題になりました。

また、Mac OSXの基幹ライブラリCore Foundationは、ライブラリ自体はC言語で書かれているにもかかわらず、その設計方針は明確にオブジェクト指向です。

継承やクラスは、オブジェクト指向の必須条件ではありません。

オブジェクト指向の本質とは、何でしょうか。

その本質とは"名前をつけて対象を識別し、それを扱うこと"、にあります。

最もプリミティブなオブジェクト指向の対象は、ファイルハンドラです。あるファイルを開いて、読み込んで、あるいは書き込んで、ファイルを閉じる。

これらの処理をまとめたら、わかりやすいですよね？

対象に関する処理を、対象の周りにまとめる。これがオブジェクト指向の基礎的な理念です。

識別することとイコールで比較できることは、とても良く似ています。

イコールによる比較は、オブジェクト指向では鬼門であることが知られています。

PointクラスのインスタンスとColoredPointクラスのイコール演算をどう決めればいいかに、正解はありません(詳しくは"effective java"をご参照ください)。

また名前をつけて識別する対象は、フワフワしていてはいけません。

たとえば、"軍人の階級"をオブジェクトにしたとしましょう。"大佐"クラスのある兵士は名前のフィールドや、性別のフィールドを持っているでしょう。

ところで彼が昇格したときに何が起こるでしょうか。

新たに"少将"クラスのインスタンスが作られます。"大佐"クラスを破棄する前に、名前、性別、その他沢山のデータを引き継がなくてはいけません。フィールドを増やしたい場合はその都度コードに修正を加える必要があります(*)。

なるべくイコール比較を避けたい。対象は不安定なものではいけない。では何に名前をつけて、識別するか。そこにオブジェクト指向技術者の熟練度が現れるのです。

関数型プログラミング的アプローチ

一方、関数型プログラミングでは、特定の何かに名前をつけるより、極力、汎用部品でなんとかしようとします。

小さな関数を、集めて撚り合わせて、新しい関数を作る。

関数自体をリストなどのデータ構造に詰めることもよく行われます。

実は、関数型プログラミングというのは本質を表していません。

その真の名は、"値指向プログラミング"です。

関数をはじめとして、リスト・ツリーのようなコンテナ、手続きを抽象化したもの、回路を抽象化したもの。

あらゆる対象を値として、合成し、ときに分解し、新しい値を作ります。

変数という概念は必要ありません。

変数に適用する処理を作りあげることが、とても簡単だからです。

四則演算が定義されたデータを詰めたデータ構造もまた、四則演算可能だったり。

値をイコール比較することも、なんのそのです。

誤解を恐れずに言うと、オブジェクト指向がトップダウンなのに対し、関数型プログラミングはボトムアップです。

関数型プログラミングの利点

読みやすい・理解しやすい

関数型プログラミングをサポートする言語には、沢山の汎用部品が定義されています。

• ファンクタ: "コンテナ"一般を表すもの。
• モナド・コモナド: "手続き"一般を表すもの。
• アロー: "回路"一般を表すもの。
• トラバーサブル: 木やリストのような、各所を周って要素に変更を加えられるデータ構造一般。
• フォルダブル: 再帰的に"畳み込めるデータ構造"一般を表すもの。

このような構造をインターフェイスとして、様々なライブラリが組まれているので、

たとえばモナドを知っていれば、30分程度でパーサー(解析機)を理解することができて、

パーサーを理解できれば、JSONパーサー・ XMLパーサー・markdownパーサー・C++パーサー ... などを理解するのはとても容易です。

理解しやすいこと。これが関数型プログラミングの大きな利点です。

追記:

また、汎用部品と型のお陰で、ライブラリのドキュメントが圧倒的にひきやすい、というメリットも有ります。

Haskellな人がPythonにトライした結果 - Togetterまとめ

書きやすい

関数型プログラミングは「厳密な事前設計を必要とするため、簡単なことをやるのにも時間が掛かる」。

よく誤解されていますが、これはウソです。

スクラッチでプログラムするのは、非常に手軽です。

＞＞ map (*2) [1,2,3]
[2,4,6]

邪魔な”儀式”や、"おまじない"のコードが徹底的に撤廃されているためです。

関数型プログラミングのコードは、潔癖かつ濃密です。

たとえばC言語でint hoge(int x,int y)が定義されているとき、hoge(3)はなんの意味も持ちませんが(コンパイルでコケますが)、関数型プログラミングでは意味があり、実際に有用です。

上の例では、「掛け算をする」(*)関数は、二引数関数ですが、それに引数を渡して作られた「2を掛ける」関数(*2)は、一引数関数になります。

関数型プログラミングでは、「簡単なことは簡単にでき、複雑なことは複雑にできる。ただし、間違ったことは殆どできないか、全くできない」。

多くのバグは、コンパイルエラーとして検出されます。

また、静的型付けの力によって、コード補完は非常に強力になっています。インテリセンスの比ではないです。

たとえば、関数中のある表記の型を任意に表示できます(GHC/TypedHoles - HaskellWiki)。

やがてやってくる未来には、プログラムをテキストエディタで書くことは時代遅れになっているでしょう。

統合環境のサポートで、バグやミスの少ない、スムーズなプログラミングができます。

そしてその環境で動くプログラミング言語は、関数型プログラミングをサポートした言語なのです。

いつ関数型プログラミングか

以下の様な兆候を感じたら、あなたはそのプログラムを関数型プログラミングで書くべきです。

• "人工物"クラスが増えてきた。
• Builderパターン、Strategyパターン、Commandパターン、Interpreterパターンが増えてきた。
• DI注入のとき、コンストラクタ注入にするか、セッター注入にするか、いつも迷う。

一般に、オブジェクト同士の相互作用が複雑になるほど、オブジェクト指向では手に負えなくなっていきます。

そういうときは、オブジェクトを直接扱わず、替わりにその"相互作用"を扱うことで、複雑さを軽減するアプローチが有効です。

それこそが関数型プログラミング的アプローチです。

オブジェクト指向の利点

初心者にとっては読みやすい・理解しやすい

特にオブジェクト指向が有効なのは、プログラミング初心者がそのコードをいじるかもしれないときです。

関数型プログラミングは、強固さと柔軟さの代償として、高い学習コストを伴います。

そのため、初学者にとってはハードルが高いのです。

扱う対象があまり複雑でない時は、書きやすい

オブジェクト間の相互作用が複雑でなく、着目している(名前をつけている)概念が安定しているとき。

そして、プログラムをいじる人たちの間で共通理解が図れているならば、オブジェクト指向が有利です。

関数型プログラミングの得意分野はなにか

数値計算

遅延評価という機能によって、レガシーな言語で扱えなかった、巨大な数を扱うことができます。

分数を扱うことができます。虚数もです。

関数型プログラミングで書かれたプログラムは、正確さが要求される、金融関連の業界で使われています。

テキスト処理

手続きとしてパーサーを記述できるので、テキスト処理プログラムはより理解しやすく、メンテナンスしやすいものになります。

関数型プログラミングを知らない人は、「正規表現でおk」と言いますが、

彼の書いた複雑な正規表現は、半年後には(書いた本人でさえ)理解できなくなっていることでしょう。

並行処理

手続き一般を扱うことができるので、途中で割り込みのある手続きの表現も容易です。

関数型プログラミングをサポートしていない言語ではコルーチン(ファイバー)などをつかってなんとかするしかありません。

さもなくば、非並行処理では普通に関数として記述できるところを、並行処理のために、Builder,Strategy,Command,Interpreterパターンを駆使して書き直すことになります。

Javascript使いの方は、Deferredなどの構造を使うでしょう(http://qiita.com/KDKTN/items/4c6986049d204f0645d8)。

C++使いの方はBoostで頑張りましょう。破滅的に解りにくいコンパイルエラーメッセージと格闘してください。

レシピ

もう少し簡単な例をあげます。

あなたは、あるレシピにしたがって、自動的に料理を行うマシンの制御プログラムを書いているとしましょう。

料理のレシピは、"手続き"ですよね？たとえば、カレー。

1. まず玉ねぎを炒める。

2. 飴色になったら、肉を加えて炒める。

3. 野菜を加える。

4. 水を加えて煮る。

5. スパイスを加える。

しかしあなたはこの手続きを関数として表現できるでしょうか。

…できませんよね？何故ならば、各ステップの"間に"、マシンのロボアームの位置や動きを調整する処理が必要だからです。

これをオブジェクト指向でやろうとすると、各ステップの副作用として、それらの処理を行うことになります。

そうすると、マシンが二機に増えた時などの変更量は、絶望的なものになります。

あるいは関数として表現するのを諦め、手順全体をDSLで記述できるようにします。

このアプローチは関数型プログラミング的です。しかし関数型プログラミングをサポートした言語の助けなしでは、そのDSLを記述するために沢山のユーティリティーコードを書かなくてはならないでしょう。

オブジェクト指向的アプローチでこの問題をエレガントに解こうとすると、クラス化の粒度を上げる事になります。

野菜クラス、フライパンクラス、ボイルクラス、フライクラス、焼き加減クラス、アームクラス、野菜の大きさクラス、切り方クラス、焼き方クラス、"焦げたよ"クラス、etc...

こうすると早晩レシピはプログラムのコード上から消え去ることになります。上記のたった5行は、依存性注入のオブジェクトグラフを構築するコードに取って代わることになります。そこには沢山の挙動の制御がオプションとして付記されているのです。

カレーなど、ある種のレシピに限定することで、見た目の理解しやすさを得ることができますが、一方それは表現力を損なうことを意味します。

C言語などではマクロを使うこともできますが、それは結局、関数型プログラミング的アプローチの意味するところと同じになります。すなわち、補助のために沢山のコードを書くことになるでしょう。

GUI

iOSのAppstoreアプリは、"無料"と書かれたボタンを押すと、それが"インストール"ボタンに変わり、それをもう一度押すと、ダウンロードの進捗を表すインジケータに変わり、それを押すとダウンロードをキャンセルできます。

このように、位置は同じなのに、ステートに依って見た目と機能が変わるボタンは複雑です。

これをオブジェクト指向で実現しようとすると、

1. 三つの異なるボタンを同じ位置に置くか

2. 同じボタンが三つの異なる機能を持つか

という下らない問題にぶつかります。

一方関数型では、"機能"、"見た目"、"状態"、を独立に扱って、それらを合成してボタンを作るので、迷うことはありません。

「同じ位置にあるUIオブジェクトは、コード上で(インスタンスとして)独立して、他から干渉を受けない」

この条件が満たされているうちは、オブジェクト指向でGUIを実現することに無理はありません。

しかし、携帯端末のような小さい画面で、多くの機能を達成するためには、UI要素はコンテキスト依存的に複雑になりがちです。

近年、PCのディスプレイの大きさは、頭打ちになってきました。

画素数は増えているのですが、MacにおけるRetinaのように、複数ピクセルでひとつのドットを表すようになってきています。

これは、ひとつの画面に置かれるボタンなどのUI要素の数は、これから先の未来で増えることはない、ということを意味します。

したがって、未来のGUIのプログラミングは、注意深く機能をピックアップして制限するというデザイナーの努力を脇におけば、

関数型プログラミングの力を頼るしか無いでしょう。

はじめよう、関数型プログラミング

つまり…

Haskell さいこうなのおおおおおおおおおおおおおおおおおお!!　おしっこ漏れちゃうのおおおおおおおおおおおおおおおおおおおお(゜∀。)ﾜﾋｬﾋｬﾋｬﾋｬﾋｬﾋｬ

1. google:すごいHaskellたのしく学ぼう を注文する。

2. Download Haskell を自分のPCに導入する。

3. コンソールにghciと入力して、対話型コンソールを立ち上げる。

4. 次の関数をコンソールに打ち込んで、結果を見る。即値で書かれているところとかをいろいろ変更してみて、感動する。

take 4 $ map (*2) [1..]

5. ステップ1で買った教科書を読んで、学ぶ。

追記:

いかがでしたか？

ちまたには、関数型プログラミングの利点は変数が無いことだ、とか、より安全だから、とか、より速いから、などという妄言が満ち溢れています。

オブジェクト指向と関数型プログラミングは、水と油ではありません。プログラマは自分のプログラムに最適なアプローチを選ぶことができます。

一般にはあまり知られていないことですが、Haskellにもオブジェクト指向へのサポートがあるんです(Lensライブラリ、これを使用したサードパーティ製ライブラリも最近増えてきています)。

この記事を読んだオブジェクト指向プログラマのあなたが、少しでも関数型プログラミングに(そしてHaskellに)興味を持ってくださって、ホームセンターの大人用オシメのコーナーが大賑わいになれば幸いです。。

Permalink | 記事への反応(8) | 01:08

ツイートシェア