【ITニュース解説】TIL: Adapter Design Pattern

システム開発では、異なるシステムやソフトウェアの部品（モジュール）同士を連携させる場面が頻繁に発生する。しかし、それぞれの部品が異なる「言葉」や「形式」で情報をやり取りしようとすると、そのままではうまく動作しないことがある。このような互換性の問題を解決するための強力な手法の一つが、「アダプターデザインパターン」である。

アダプターデザインパターンは、インターフェースが互換性のないクラス同士を、間に「アダプター」という仲介役を挟むことで連携させるデザインパターンである。ここで言う「インターフェース」とは、簡単に言えば、ある部品が提供する機能の「入り口」や「出口」の形式、つまり、どのような情報を受け取り、どのような情報を返すかという取り決めのことだ。例えば、ある部品は数値を「メートル」単位で渡すことを期待するが、別の部品は「インチ」単位でしか情報を提供できない、といった状況がこれに該当する。

具体的な例として、自動車の製造工場を考えてみる。この工場には、車の部品を設計する「設計部門」と、設計された部品が正しく機能するかを調べる「テスト部門」がある。本来、設計部門が作った設計図や試作品をテスト部門が受け取って検証することで、スムーズに開発が進むはずだ。しかし、設計部門は伝統的に「インチ」や「ポンド」といった「ヤード・ポンド法」の単位で設計を行っており、その結果として出てくる部品の寸法や重さの情報もヤード・ポンド法で提供される。一方、新しく導入されたテスト部門は、最新の計測機器や国際標準に合わせ、「センチメートル」や「キログラム」といった「メートル法」の単位でしかテストを行うことができない。

この状況では、設計部門が提供する情報とテスト部門が期待する情報の間に大きな隔たりがあり、両部門は直接連携することができない。設計部門の成果物をテスト部門がそのまま受け取っても、単位が違うため正しく理解し、評価することができないのだ。互いに「相手の言葉が分からない」状態と言える。

この問題を解決するために、工場は「アダプター部門」を新設する。このアダプター部門の役割はただ一つ、設計部門からヤード・ポンド法で提供された部品のデータを受け取り、それをテスト部門が理解できるメートル法へと正確に変換することだ。例えば、設計部門が「長さ20インチ」の部品情報を提供した場合、アダプター部門はそれを「長さ50.8センチメートル」（1インチは約2.54センチメートル）に計算し直し、単位も「cm」に変換してテスト部門に引き渡す。こうすることで、テスト部門はメートル法のデータとして部品情報を受け取ることができ、滞りなくテスト作業を進められるようになる。設計部門もテスト部門も、それぞれの作業方法や内部システムを変更することなく、円滑な連携が実現するのだ。

これをプログラミングのコードで見てみよう。 まず、「設計部門」はEngineeringDepartmentというクラスで表現される。このクラスはprovideMeasurements()というメソッドを持っており、呼び出されると「長さ20インチ」というヤード・ポンド法のデータ、つまり{ length: 20, unit: "inches" }という形式のオブジェクトを返す。これは、従来のシステムや既存のライブラリが提供する、変更できない、あるいは変更が難しい機能だと考えられる。

次に、「テスト部門」はTestingDepartmentというクラスで表現される。このクラスはtestPart(part)というメソッドを持っており、部品情報を引数として受け取ることを想定している。しかし、このテスト部門は「センチメートル（cm）」単位のデータが与えられることを前提としている。つまり、partオブジェクトにはlengthがセンチメートルで、unitが"cm"であると期待しているのだ。

ここで登場するのが、「アダプター部門」にあたるEngineeringToTestingAdapterクラスである。このクラスは、まさに互換性のない二つの部門の橋渡しをする役割を担う。EngineeringToTestingAdapterのコンストラクタは、引数としてEngineeringDepartmentのインスタンスを受け取る。これは、「どこの設計部門からの情報を変換するのか」を指定していることになる。

アダプターの核となる機能はgetMetricMeasurements()メソッドである。このメソッドが呼び出されると、まず内部でコンストラクタで受け取ったengineeringDept（設計部門）のprovideMeasurements()メソッドを呼び出し、ヤード・ポンド法の部品データ（{ length: 20, unit: "inches" }）を取得する。次に、取得したヤード・ポンド法のデータ（ここではimperialという変数に格納されている）を使って、単位変換の処理を行う。具体的には、imperial.length（インチ単位の長さ）に2.54を掛けてセンチメートルに変換し、単位も「cm」に設定し直す。そして、変換されたメートル法のデータ{ length: imperial.length * 2.54, unit: "cm" }を返す。

実際の利用シーンでは、まずengineeringというEngineeringDepartmentのインスタンスを生成する。次に、このengineeringインスタンスを引数としてadapterというEngineeringToTestingAdapterのインスタンスを生成する。これでアダプターが設計部門と接続された状態になる。そして、testingというTestingDepartmentのインスタンスも生成する。

いよいよ連携の段階だ。テスト部門が部品情報を受け取るために、直接設計部門に働きかけるのではなく、アダプターに依頼する。adapter.getMetricMeasurements()を呼び出すことで、アダプターが設計部門から情報を取得し、変換したメートル法のデータがpartForTesting変数に格納される。このpartForTestingは、テスト部門が期待する「長さ50.8センチメートル、単位はcm」という形式になっている。最後に、このpartForTestingをtesting.testPart(partForTesting)としてテスト部門に渡すことで、テスト部門は問題なく部品のテストを実行できる。コンソールには「Testing part of length 50.8 cm」と表示され、正常に動作したことが確認できる。

このように、アダプターデザインパターンは、既存のコードやシステム（レガシーシステム、サードパーティライブラリなど）を変更することなく、新しいシステムや異なるインターフェースを持つシステムと連携させる必要がある場合に非常に役立つ。既存のコードの安定性を保ちつつ、新しい要件や技術に対応できるようになり、システム全体の柔軟性や再利用性を高めることができるのだ。異なる部品同士が「言葉の壁」を越えて協力し合うための、シンプルかつ強力な解決策がアダプターデザインパターンなのである。