FAIC モナド、パート1

2018-01-19 07:53:18

原文

たくさんのブロガーが先にやってることだけど、そんなの知るか。私もやるぞ。今回の連載記事では次の質問に答えを出すつもりだ。

私は「関数型プログラミング」の類をまったく知らないC#プログラマーです。「モナド」とかいうのを聞いたことがあるのですが、それって何なんですか。そして私に使い道があるんでしょうか？

ブロガー達がこの問題に取り組むとき、いきなり関数型プログラミングの用語を説明し始めることが多い。「bind」や「unit」という操作だったり、高階型による高階関数プログラミングだったり。もっとひどいパターンだと、モナドの理論的背景である圏論までずっとさかのぼって「単なる自己関手の圏におけるモノイド対象だよ。何か問題でも？」とかなんとか説明し始める場合もある¹。私はもっと実践的で、オブジェクト指向で、C#の型システムが主眼を置いているところから始めたい。関数型プログラミングという雲の上の高みに向かうのはそれからだ。

オブジェクト指向プログラマーは「デザインパターン」の話が好きだから、これを使って話の枠を設定したい。

「デザインパターン」という考え方は、リアルに建物を建てる系のアーキテクチャから来ている。何千年もの間、人類が建ててきたもののアーキテクチャには同じパターンが何度も現れていることは言うまでもないことだろう。壁とか、扉とか、窓とか、天井とか、支柱とか、玄関とか、中庭とか、はね橋とか、堀とか、押入れとか、台所とか。これらのものはすべてお互いに関連しあっている。ドアも窓もない中庭は便利とは言えないように。そしてこれらのパターンおよび関連性は時代や場所を超えてとても安定している。ペンタゴン（米国防総省）と1900年前のローマ様式ヴィラには、時代も場所も大きな隔たりがあるにもかかわらず、明らかにいくつものパターンが共通している。

同じことはソフトウェアでも言える。同じと思われるパターンが何度も何度も繰り返されていることを私たちは知っている。関数とか、変数とか、型とか。これらのパターンはプログラミング言語に深く浸透し、息をするのと同じぐらいに馴染んでいるため、これらがデザインパターンであると気づくことは少ないが、実際はそうなのだ。したがって、私たちがデザインパターンについて議論するとき、言語の一部ではなく開発者によって明示的に実装されるべきものは、ほぼ常にパターンのコンテキストの中にある。

たとえばC#では、シングルトン・パターンは言語に"焼きこまれて"はいない（前回その話をした）。しかしそうなっていてもよかったのだ。静的クラスや抽象クラスみたいに、 singleton class C { ... } と書けるような特別な文法があってもよかった。C#の言語設計者は、ファーストクラスな言語機能として昇格させるほど重要だとは考えなかったので、シングルトンがほしい開発者は自分で「パターンに従う」必要がある。

シングルトン・パターンが型に関するデザインパターンであるのと全く同じように、モナド・パターンも型に関するまた別のパターンというだけのことだ。このパターンはさまざまな問題の解法の「かたち」を表している。モナド・パターンに関するものごとは、シングルトン・パターンとは異なり、気づかれにくくできるのだ。多くの開発者たちが、モナド・パターンをまったく偶然に使用している。すでに名づけられているものを再発明しているとは気づかずに。

うへ、初回からちょっと気取りすぎたかも。それはいちばん避けたいと思うところなのに。次回のFAICはモナド的な要素を持つ型についていくつか実例を見てもらい、何が共通しているのかをわかってもらうつもりだ。

インデックスへ戻る