オブジェクト指向とカリー化
「巻き」が入る中、最後に登場したGeekは津田嘉孝氏。「オブジェクト指向とカリー化」と題された発表は4月に行われたもので、「カリー化の意義を理解する」ことを目標としたものである。そもそもこの資料は、お客様先で勉強会を実施するために制作したものだという。
このお客様は業界大手で、Java Webアプリケーション開発を多数実施しており、フレームワークも所有していたが、開発効率に課題があるため、日本アイ・ビー・エム システムズ・エンジニアリング株式会社（以下、ISE）にて、Seasar2をベースにした新規フレームワークを開発・保守していた。2008年に入ってから、その追加機能を含む保守をお客様が引き継ぐに当たり、技術力向上を目指し、勉強会を実施することになった。その中でオブジェクト指向とカリー化を取り上げたのだという。
閉じた世界と開かれた世界
津田氏はまず、「閉じた世界と開かれた世界」として比較を行った。ここで言う閉じた世界とは、メインフレームに代表される決まりきった接続先だけの世界で、開かれた世界とはLinuxやWindows、AIXなどのOS、Javaや.NET、Ruby、PHPなどの言語に代表されるように多種多様な接続先がある世界だ（ここで"The Internet"のinterが「～間の」という意味があることを考えると閉じたネットワーク同士が結びつきあうことで開かれたネットワークを形成していったことが感じ取れる）。
さて、閉じた世界ではプログラムの考慮点がほとんどないため、メソドロジーとして構造化設計手法を採用し、単純にサブルーチン化していけば、サブルーチン呼び出しによる再利用が達成される。そのため開かれた世界に比べ閉じた世界では生産性を高く維持することが可能だ。
一方、開かれた世界では、プログラムの考慮点はセキュリティやアーキテクチャ、プロトコル、フレームワークなど多数存在し、かつ、旧来の手法では、これらへの対応項目が増えるほどコード量が爆発的に増えてしまう傾向がある。つまり、世界が開かれていくほど考慮事項が増え、生産性は下がっていく、そのため、開かれた世界のメソドロジーとして、オブジェクト指向が注目されてきたのである。特に開かれた世界では、状況を特定できないという辛さがあると津田氏は言う。
状況を特定できないことの苦労
例えば、ResourceBundleを使ってプロパティファイルからキーに対して値を取得することを考えた場合、もし、この世界に住むすべての人間が英語だけを使用しているのなら
bundle.getBundle(key)
だけで済む。しかし、日本語などの国際化対応を考慮した途端
bundle.getBundle(key, request.getLocale())
と、ロケールに気を遣う必要がでてくる。また、JavaEEコンテナから利用される状況まで考慮しだせば、アプリケーションのClassLoaderまで特定する必要が出てくるため、
bundle.getBundle( key, request.getLocale(), Thread.currentThread().getContextClassLoader())
のように記述が複雑になってくる。本来、キーに対して値が欲しいだけなのに、場合によっては状況の特定にコード上でこれだけの努力が必要となるのだ。
また状況が変わった場合、例えば、アメリカで作られたアプリケーションでは最初a）の記法を用いて記述されていたが、ある日、日本にも進出しようと考えた結果、国際化対応でb）のような修正が発生したとしても不思議ではない。
このように旧来の手法では状況に変化が現れた結果、パラメータもすべて書き直すことになり、ひいてはアプリケーションを作り直すことにまで繋がる。この原因はレイヤーの上から下まで必要なパラメータを引き渡していかなければならないことにある。もし、要件の追加だけですべて作り直さなければならないのであれば、レイヤー化に意味はない。
この課題に対し、パラメータはそのままに要件の追加を可能にするのが、オブジェクト指向が目指したことであり、本質的な答えをコンピュータサイエンスに求めれば、それは「カリー化」ということになる。
