# 目次
# はじめに
以下の記事は，オライリージャパン社から出版された
『プログラマが知るべき97のこと』
の中から1つのエッセイを選び，
そのエッセイを，クリエイティブコモンズ3.0の条件の元で転載したものです．
Creative Commons ― 表示 3.0 アメリカ合衆国 ― CC BY 3.0
もし，他のエッセイを読みたい場合には，
記事末のリンクを辿るか，
以下のリンク先のTwitterアカウントのつぶやきからお探し下さい．
Twitter Account: 97 Things Bot
02 関数プログラミングを学ぶことの重要性 エドワード・ガーソン(Edward Garson)
最近，
プログラミングコミュニティでは，
再び，関数型プログラミングへの関心が高まっています．
その理由としては，業界全体でマルチコアへの移行が進んでいる，
ということもあるでしょう．
移行によって生じる新たな課題への対処に，
関数型パラダイムの持つ特性が
うまく合致することが明らかになってきたからです．
確かにそれも重要な理由です．
しかし，仮にそれだけなら，
私がここでわざわざ「あなたも関数型プログラミングを学ぶべき」
という文章を書くこともなかったと思います．
関数型プログラミングのパラダイムを十分に学べば，
その知識，技術は，
マルチコアへの対応以外にも幅広く役立つでしょう．
まず，自分の書くコードの品質を大きく高めることができす．
重要なのは，
参照透過性(referential transparency)
が向上するということです．
参照透過性が高いということは，
非常に素晴らしいことです．
参照透過性が高いとは，
関数がどこでいつ呼び出されようとも，
入力が同じであれば，
常に得られる結果が同じになるということを意味します．
つまり，
関数の評価結果が状態変化の副作用に左右されることが，
少ない（あるいはまったくない）ということなのです．
手続き型プログラミングに不具合が生じる原因となりやすいのが，
「可変(mutable)な変数」です．
本書の読者なら，
ある変数の値が，状況によって予測した通りにならず，
その理由を調べた経験が少なからずあるでしょう．
「可視性セマンティクス(visibility semantics)」などが，
そうした目に見えにくい不具合を減らす上で役立つことはありますし，
少なくとも，不具合の箇所の絞り込みにかなり役立つことは，間違いないでしょう．
しかし，ここで本当に問題なのは，
そもそも，変数の値が変わってしまうような設計をしてしまったことです．
そういう設計を防ぐために参考になるものは，
業界全体を見渡してもあまり見つからないのは確かです．
オブジェクト指向言語の入門書などには，
変数の値が変わる設計を暗黙のうちに助長してしまっているものもあります．
比較的「長生き」するオブジェクトたちが，
お互いの値や状態を変えるメソッド(mutator methods)を次々に呼び出す，
というようなプログラム例が図解入りで載っていたりするからです．
これはとても危険です．
しかし，
適切なテスト駆動設計*1をすれば，
特に「オブジェクトではなく，ロールのモックを作成すること」
を心がけるようにすれば，
不要な可変性は，設計から排除できるでしょう．
大事なことは，
可変なメンバー変数の参照が必要となるような設計をしないことです．
それよりも，小さな関数を数多く作り，
個々の役割を限定する方が得策です．
個々の関数は，自らに渡される引数にのみ作用するようにします．
そうすれば，不具合は減り，
おそらくデバックも簡単になるでしょう．
この設計では，
仮に変数に不適切な値が入ったとしても，
その箇所を特定するのが容易になるからです．
そうではない設計では，
不適切な代入がどのような前後関係で行われたかを推測する，
ということまで行う必要があるのです．
このように参照透過性を高めることは非常に大切ですが，
それを血肉となるくらいに深く理解には，
関数型プログラミング言語を学ぶのが一番でしょう．
関数型の言語では，
参照透過性の高いプログラムを書くことがごく当たり前だからです．
もちろん，参照透過性を高めることが，
どんな状況でも好ましいということではありません．
参照透過性を高めるようなスタイルは，
オブジェクト指向システムの場合，
ユーザインタフェース開発よりも，
例えば，ドメインモデル開発において，
(つまり，コラボレーションがビジネスルールの複雑さの低減に役立つような場合に)
好結果につながりやすいでしょう．
関数型プログラミングのパラダイムについてよく学ぶことで，
関数型言語での開発以外の場合にも，
学んだことをうまく応用できるでしょう．
オブジェクト指向システムであっても，
参照透過性を高めることができれば，
利益は大きいはずです．
一般に信じられているよりも，
オブジェクト指向システムと関数型システムの間に違いはありません．
中には，
「突き詰めれば，
関数型プログラミングとオブジェクト指向プログラミングは，
どちらもお互いの鏡像にすぎない」
などどいう人もいます．
「陰と陽」のような関係，
と言ってもいいかもしれません．
■著者データ
[エドワード・ガーソン (Edward Garson)]
Apple II でLOGOを使ってプログラミングを学んで以来，
コンピュータに情熱を傾けてきた．
現在はフリーのソフトウェア開発コンサルタントとして働いている．
主に力を入れているのは，
アジャイル手法に移行する企業の支援である．
個人的に関心が強いのは，
ソフトウェアアーキテクチャと設計，
プログラミング言語，
GNU/Linuxなど．
ブリティッシュ・コンピュータ・ソサエティ，
マイクロソフト，
アーキテクツ，カウンシルに他，
カンファレンス等で精力的にプレゼンを行なっている．
『ソフトウェアアーキテクトが知るべき97のこと』
オライリージャパン
売り上げランキング: 24516
の寄稿者でもある．
妻と2人の息子と共に
モントリオールに住む．
趣味はスキー，登山，サイクリングなど．
MyEnigma Supporters
もしこの記事が参考になり、
ブログをサポートしたいと思われた方は、
こちらからよろしくお願いします。
*1:テスト駆動開発 (てすとくどうかいはつ、test-driven development; TDD) とは、プログラム開発手法の一種で、プログラムに必要な各機能について、最初にテストを書き（これをテストファーストと言う）、そのテストが動作する必要最低限な実装をとりあえず行った後、コードを洗練させる、という短い工程を繰り返すスタイルである。テスト駆動開発 - Wikipedia
