Adapter

パターンの目的

p.149,line.3-5: あるクラスのインターフェイスを、クライアントが求める他のインターフェイスへ変換する。Adapterパターンは、インターフェイスに互換性のないクラス同士を組み合わせることができるようにする。

GoF パターンのクラス図

MixJuice 版 クラスに適用する Adapter (別解1)

解決される GoF パターンの問題点

拡張性の問題点

p.153 「adapter の潜在的な問題は、すべてのクライアントに対して透過性がないことである。適合されたオブジェクトは、もはや Adaptee クラスのインタフェースには従っていない。そのため、本来の Adaptee オブジェクトと同じように使用することはできなくなる。」

p.143, line.9-12, A potential problem with adapters is that they aren't transparent to all clients. An adapted object no longer conforms to the Adaptee interface, so, it can't be used as is whenever an Adaptee object can.

補足：既存ソースコード中の各サブクラスのインスタンス生成している箇所を、新たに追加したサブクラスの名前に変更しなければならない。

クラス数増加の問題点

p.152,line.11-13: Adaptee クラスの Target クラスへの適合を、具象クラス Adapter に任せる。結果として、あるクラス、およびそのすべてのサブクラスを適合させたいときに、クラスに適用する Adapter パターンではうまくいかない。

補足：具体的になにがうまくいかないのかを以下に説明する。既存のあるクラスが n 個のサブクラスを持っており、この n 個のクラスすべてを適合させたい場合を考える。この n 個のクラスを、さらにサブクラスすることによって、そのインターフェースを適合させるには n 個の新しいクラスを作らなければならずコード記述量が多い上、サブクラスが増えるたびにそれに対応する Adapter クラスも増やさなければならない。なお、適用可能性の節の３項目めに述べられているように、「オブジェクトに適用する Adapter パターン」ならば、 n 個のサブクラスすべてを一度に適合させることが可能である。

対策

スーパーインターフェースを追加する。これは GoF パターンの別解である。

結果

あるクラスおよびそのすべてのサブクラスのインターフェースを一度に適合させることができる。既存のソースコードの修正は不要である。

ただし、「両方向 adapter」は扱えない。これはクラスの多重継承が必要なためである。

構造

module library {
  define class Adaptee {
    define void specificRequest() {...}
  }
  define class SubAdaptee extends Adaptee {...}
}
module application extends library {
  define interface Target {
    define void request();
  }
  class Adaptee implements Target {
    void request() { specificRequest(); }
  }
}

MixJuice によるデザインパターン改善カタログ