デザインパターンとＨＯＰ
プログラミングの世界では、抽象化は非常に重要な設計作業である。プログラミングスタイルの歴史は、抽象化手法の歴史でもあるわけだ。何を抽象化するかがプログラミング手法を区別している。
では、抽象化とはなにをすることかというと
- 複数のものから構成されているものに「名前」を付けて、ひとつの対象とし て扱うこと
- 類似するパターンを共通部分と相違部分に分離し、相違部分を「パラメータ 化」すること
である。また抽象化はなんのためにするか、抽象化によってもたらされるのは、
- 名前による対象が認識とその性質への理解
- 名前による再利用性
なのである。
再利用性という性質は、ソフトウェアを確実に素早く構成するためには不可欠なコードの性質である。大きな単位で再利用できるほど、その効果は高い。再利用するものの単位の大きさは、プログラミングの際に課題をどれほど抽象的に記述できるかにかかっている。
粒度の大きい再利用性というものを考えたとき、デザインパターンを思いだす。よく出会う問題があって、それに対応する良い（誤りなく、所定の性能をもつ）コーディングができたとき、そのコツやノウハウを再利用できれば、すくなくとも同様の問題には迅速に対応でき、頑健なプログラムを作成できると期待できる。デザインパターンはそのようなノウハウに名前を付けて再利用できるように特定の規則にしたがってカタログにしたものである。
ＯＯＰ（Object Oriented Programming）技法の世界ではＧｏＦ（Erich Gamma、Richard Helm、Ralph Johnson、John Vlissides）によるカタログが有名である。
ところで、ＧｏＦのカタログは「デザインパターン」のカタログであって、「コーディングパターン」のカタログではないようである。つまり、コーディングの際の指針であっても、コードではないだ。これは、意図的に特定の言語でのコーディングパターンになることを避けたのだろうか。その方が汎用性が高いと考えられるからだろうか。
しかし、プログラマとしては、まさにコーディングをするときにそのまま再利用できるものが欲しい。
プログラミングという工程の範囲はいろいろな立場や考え方によって、小さくもなり、大きくもなるが、いずれにせよ、仕様をプログラムに変換する作業が含まれている。狭義のプログラミング、あるいは、コーディングという作業部分である。この仕様とプログラムの間にギャップがあって、ここを上手く乗り越えないと正しく動作するプログラムを作れない。そこで、コーディングの前にプログラムデザインをすることになる。ところが、設計とプログラムコードの間にはやはりギャップがある。仕様や設計がいくらうまくできていても、このギャップが越えられなければ、正しく期待通りの動作をするプログラムは作れない。
だから、設計パターンのカタログだけでなく、その設計パターンをコーディングしたカタログが欲しいのだ。設計パターンカタログというだけなら、それは１つ目の抽象化（名前を付けた）にすぎない。２つ目の抽象化（相違部分のパラメータ化）が欲しいのである。それも、プログラミング言語がその機能を持っていれば、設計パターンと同等の抽象度で、コーディングパターンとして使える。
この抽象化は、コードをパラメータ化することであり、「プログラム」を「プログラム」することに他ならない。高階プログラミング、ＨＯＰ（Higher-Order Programming）！！
いま手元にある言語では、高階プログラミングができるかな。