【ITニュース解説】Composite Pattern in Clprolf — Example with Files and Folders

システムエンジニアを目指す皆さんにとって、プログラムをどのように設計するかは非常に重要なテーマだ。今回は、たくさんのオブジェクトを扱う際に役立つ「Composite Pattern（複合パターン）」という設計パターンと、それを「Clprolf」という新しい技術でどう実装するかに焦点を当てて解説する。

まず、Composite Patternがどんな問題を解決するのかを考えてみよう。私たちは普段、パソコンでファイルやフォルダを扱う。ファイルはそれ単体で存在し、フォルダはファイルや他のフォルダを中に含めることができる。しかし、これらの操作は「ファイル」に対しても「フォルダ」に対しても同じように行いたい場合がある。例えば、「この要素を削除する」といった操作だ。ファイルならそれ自体を削除し、フォルダならそのフォルダと中身すべてを削除する。このように、単一のオブジェクト（ファイル）と、複数のオブジェクトをまとめたグループ（フォルダ）を、プログラム上では同じように扱いたい、というニーズがComposite Patternの出発点となる。

従来のオブジェクト指向プログラミング（OOP）では、この問題を解決するために通常三つの要素を定義する。一つ目は「Component（コンポーネント）」という共通のインターフェース。これはファイルとフォルダが共通して持つべき操作（例えば「情報を表示する」など）を定義する役割を担う。二つ目は「Leaf（リーフ）」と呼ばれるクラスで、これはファイルのように、それ以上子要素を持たない単一のオブジェクトを表す。三つ目は「Composite（コンポジット）」と呼ばれるクラスで、これはフォルダのように、Componentインターフェースを実装する他のオブジェクト（ファイルや他のフォルダ）を内部に持つことができる。Compositeクラスには、子要素を追加したり削除したりするメソッドが用意される。この方法でComposite Patternは実現できるのだが、どのクラスがLeafで、どのクラスがCompositeなのかは、プログラムの慣習や開発者の暗黙の了解に頼る部分が多く、コードを読んだだけではすぐに理解しにくいという課題があった。

ここで「Clprolf」という新しいアプローチが登場する。Clprolfでは、「役割（roles）」と「契約（contracts）」という概念を導入することで、Composite Patternをより明確に、そしてあいまいさなく表現できるようになった。

ClprolfでのComposite Patternの仕組みを見ていこう。まず、すべてのファイルシステムコンポーネントが共通で満たすべき「契約」として「FileSystemComponent」が定義される。これは、従来のOOPにおけるComponentインターフェースに相当する。この契約には、例えば「done()」という共通の操作が含まれる。

次に、具体的なファイルとフォルダを表現する「抽象化」が定義される。「File」という抽象化は、FileSystemComponentの性質を持つが、それ以外の特別なメソッドは持たない。これが「Leaf（葉）」の役割を明確に示している。つまり、Fileは単一の要素であり、子を持たないことが契約上明らかになる。

一方で、「Folder」という抽象化もFileSystemComponentの性質を持つが、これにはさらに「add()」と「remove()」というメソッドが追加されている。これらのメソッドは、FileSystemComponent型の他の要素（ファイルや他のフォルダ）を内部に追加したり削除したりする機能を提供する。これが「Composite（複合）」の役割を明確に示しており、Folderが子要素を持つことができる容器であることを契約で表現している。

そして、これらの抽象化に従って、具体的な実装クラスが作られる。「FileImpl」はFile抽象化の契約を尊重し、内部にファイル名を持ち、自身の情報（「Leaf File: [ファイル名]」）を表示するdone()メソッドを実装する。「FolderImpl」はFolder抽象化の契約を尊重し、内部にフォルダ名と子要素のリストを持つ。add()とremove()メソッドは子要素リストの操作を実装し、done()メソッドでは自身の情報（「Composite Folder: [フォルダ名]」）を表示した後、内部に持つすべての子要素に対しても再帰的にdone()メソッドを呼び出す。この再帰的な呼び出しによって、フォルダの中のフォルダ、その中のファイルといった階層構造全体を一度の操作で処理できるようになる。

実際の使い方を見てみよう。「CompositePatternLauncher」というプログラムは、まず「Root」という名前のフォルダを作成する。次に「Documents」という名前のフォルダと、「File1.txt」という名前のファイルを作成する。そして、「Documents」フォルダに「File1.txt」を追加し、「Root」フォルダに「Documents」フォルダを追加する。最後に「Root」フォルダに対してdone()メソッドを呼び出すと、プログラムは「Root」フォルダの情報、次にその子である「Documents」フォルダの情報、さらにその子である「File1.txt」の情報を順に表示していく。これは、あたかもフォルダ全体を一つのまとまりとして扱っているかのように見える。

ClprolfがComposite Patternをこれほど明確にするのは、いくつかの理由がある。一つは「契約がすべてを示す」点だ。Fileは追加のメソッドを持たないためLeafであることが一目瞭然であり、Folderはadd()やremove()メソッドを持つためCompositeであることが契約から直接読み取れる。両者ともFileSystemComponentであることも示されているため、共通の操作が可能であることがすぐにわかる。二つ目は「各Compositeがシンプルである」こと。Folderは自分自身の直接の子要素だけを管理し、それ以上の複雑な階層構造の管理はしない。階層全体を処理する能力は、先ほど説明したdone()メソッドの再帰的な呼び出しによって実現されるため、Compositeクラス自体がシンプルに保たれる。三つ目は「役割が曖昧さを防ぐ」こと。実装クラス（FileImplやFolderImpl）は、それぞれが担うFileまたはFolderの役割（契約）を厳密に守るため、LeafとCompositeの役割が混同されることはない。

結論として、従来のOOPではComposite Patternはインターフェースとポリモーフィズム（多態性）を駆使した「テクニック」として教えられることが多かった。しかしClprolfでは、Leafとは「子を持たない抽象化」、Compositeとは「FileSystemComponent型の子を持つ抽象化」というように、その本質が契約として直接表現される。これにより、Composite Patternは単に覚えるべき設計パターンではなく、コードの契約を読めばその意図が自然と理解できる、非常に明快なものとなるのだ。