【ITニュース解説】Clojure's Solutions to the Expression Problem

ソフトウェアを開発する際、プログラムが将来の変更や機能追加に柔軟に対応できることは非常に重要だ。しかし、この「拡張性」を高いレベルで維持することは、実は非常に難しい問題である。特に、新しい種類のデータ（例えば、新しい種類の図形）を追加したいときと、既存のデータに対して新しい操作（例えば、図形の新しい計算方法）を追加したいとき、どちらか一方を簡単にできると、もう一方は非常に難しくなるというジレンマが存在する。このジレンマは「Expression Problem」（表現の問題）として知られ、ソフトウェア設計における古典的な課題の一つとして認識されている。

Expression Problemとは、簡潔に言うと、プログラムのデータ型（扱う情報の種類）を容易に拡張できることと、プログラムの操作（その情報を処理する機能）を容易に拡張できることの両立が難しいという問題である。一般的なプログラミングパラダイムでは、どちらか一方に優位性があり、もう一方が犠牲になりがちだ。

たとえば、オブジェクト指向プログラミングを考えてみよう。このパラダイムでは、データとそのデータを操作する関数（メソッド）を「オブジェクト」という単位で一体化させる。もし、図形を扱うプログラムで、円や四角形といった既存の図形に加えて、新たに三角形という図形を追加したい場合、新しい「Triangle」クラスを作成すればよく、これは比較的容易だ。しかし、既存のすべての図形（円、四角形、三角形）に対して、例えば「周長を計算する」という新しい操作を追加したい場合はどうだろうか。この場合、既存のCircleクラス、Squareクラス、そして新しく追加したTriangleクラスのそれぞれに、周長計算のメソッドを追加する必要がある。データ型（クラス）を追加するのは容易だが、操作（メソッド）を追加しようとすると、既存のすべてのデータ型に手を入れる必要が出てくるため、変更が広範囲にわたってしまうという問題が生じる。

一方、関数型プログラミングのアプローチでは、データと操作を分離して考えることが多い。データは純粋なデータ構造として定義され、操作はデータを受け取って処理する独立した関数として定義される。もし、図形を扱うプログラムで、既存の「描画する」や「面積を計算する」といった操作に加えて、「周長を計算する」という新しい操作を追加したい場合、新しい「calculate-perimeter」関数を定義すればよく、これは比較的容易だ。この関数は、与えられた図形データ（円、四角形、三角形など）の種類に応じて適切な計算を行う。しかし、既存の円や四角形に加えて、新たに三角形というデータ型を追加したい場合はどうだろうか。この場合、既存の「描画する」関数や「面積を計算する」関数など、図形データを扱うすべての関数に対して、新しく追加した三角形のデータ型を処理するためのロジックを追加する必要がある。操作（関数）を追加するのは容易だが、データ型（構造）を追加しようとすると、既存のすべての操作に手を入れる必要が出てくるため、これもまた変更が広範囲にわたってしまうという問題が生じる。

このように、オブジェクト指向と関数型のどちらのアプローチも、一見異なる形ではあるが、Expression Problemに直面する。プログラムの設計者は、どちらの種類の変更がより頻繁に発生するかを予測し、その予測に基づいて一方の変更を容易にする選択を迫られることになる。

しかし、Clojureというプログラミング言語は、このExpression Problemに対して独自の、そして強力な解決策を提供している。Clojureは関数型言語の特徴を持ちながら、Java仮想マシン（JVM）上で動作し、オブジェクト指向の概念とも連携できる。ClojureがExpression Problemを解決するために活用する主なメカニズムは、「マルチメソッド」と「プロトコル」である。

まず、「マルチメソッド」について説明する。一般的なオブジェクト指向プログラミングにおけるメソッドは、特定のクラスに属しており、そのクラスのオブジェクトに対してのみ呼び出される。しかし、Clojureのマルチメソッドは、関数が特定のデータ型に縛られることなく、その関数に渡される引数の種類や値、あるいはその他の任意の条件に基づいて、実行時に最適な実装を動的に選択できる仕組みである。プログラマーはまず「defmulti」という命令で汎用的な関数を定義し、その関数が引数からどのような情報を抽出して処理を分岐させるか（これを「ディスパッチ関数」と呼ぶ）を指定する。次に、「defmethod」という命令を使って、特定の条件（例えば、引数が特定のデータ型である場合など）に対応する具体的な実装を登録していく。 この仕組みにより、データ型とその型に対する操作を分離し、より柔軟に拡張できる。例えば、新しい種類の図形（データ型）を追加したい場合でも、既存の描画関数や面積計算関数を直接変更する必要はなく、新しく追加した図形型に対応する描画メソッドや面積計算メソッドを「defmethod」で追加するだけでよい。既存の汎用関数（マルチメソッド）は、新しい型の図形が渡されたときに、自動的に適切な新しいメソッドを選択して実行する。同様に、既存の図形すべてに対して新しい操作（例えば周長計算）を追加したい場合も、周長計算用の新しい汎用関数（マルチメソッド）を定義し、各図形型に対応する周長計算メソッドを登録していけばよい。既存のデータ型や操作を修正することなく、拡張が可能になるのだ。これは、データ型と操作の間の強い結びつきを緩和し、どちらの側面からもプログラムをオープンに拡張できる強力な手段を提供する。

次に、「プロトコル」について説明する。Clojureのプロトコルは、Javaのインターフェースに似た概念だが、より柔軟性が高い。プロトコルは、特定のデータ型が実装すべき操作のセット（つまり、抽象的な振る舞い）を定義する。たとえば、「図形」というプロトコルを定義し、そのプロトコルが「描画する」という操作を持つとしよう。 プロトコルの強力な点は、既存のデータ型、特に他のライブラリやフレームワークが提供するような、自分が直接制御できない既存の型に対しても、後からそのプロトコルの実装を追加できることだ。これは「アドホック多態性」とも呼ばれる。具体的には、「defprotocol」でプロトコルを定義し、その後「extend-type」や「extend-protocol」という命令を使って、既存のデータ型（例えば、ClojureのマップやJavaのStringクラスなど）に、そのプロトコルが定義する操作の実装を「後から」追加できる。 これにより、プログラマーは、既存のデータ型の定義を変更することなく、そのデータ型に新しい操作の振る舞いを「注入」できる。Expression Problemの観点から見ると、これは新しい操作を追加したい場合に、既存のデータ型を一切変更せずに、その操作を追加できる手段となる。プロトコルを使用することで、データ型と操作の密接な結合をさらに緩和し、モジュール性を高めることができる。

Clojureが提供するこれらの仕組み、特にマルチメソッドとプロトコルは、データ型と操作というソフトウェアの二つの主要な構成要素の間に存在するExpression Problemのジレンマを効果的に解消する。これらは、データ型と操作を柔軟に分離し、どちらの種類の拡張も、既存のコードへの影響を最小限に抑えながら行うことを可能にする。これにより、Clojureで書かれたプログラムは、将来の変更や機能追加に対して、より適応性が高く、保守しやすいものとなる。ソフトウェアの寿命が長くなり、進化する要件に対応し続けることができるのは、このような設計上の柔軟性があるからに他ならない。Clojureは、データと振る舞いの関係を深く考察し、開発者が直面する一般的な課題に対して洗練された解決策を提供する言語の一つと言えるだろう。