Adapter Pattern (アダプター・パターン) : 互換性のないインターフェイスを持つクラスが一緒に動作できるように、インターフェイスをクライアントが望む別のインターフェイスに変換するパターン。アダプタ・パターンは、クラス構造化パターンとしてもオブジェクト構造化パターンとしても使うことができます。
デザインパターンそのものの目的は、ソフトウェア設計をより合理的に、疎結合にし、拡張しやすくすることであるはずです。書籍でもブログでも、パターンの定義やUML図、基本的な実装方法について書かれているのが一般的です。しかし、私見ですが、パターンの実装や応用は、パターンそのものの構造に従う必要はないように思います。
SpringMVCのアダプタパターンは、主に対象のControllerでリクエスト処理メソッドを実行するために使われます。
いくつかの情報を読んでみたところ、Adapter を使う目的は if の使用を減らし、大量のリクエスト処理コードと DispatcherServlet の結合を減らすことだと感じました。Handlerによってリクエスト処理メソッドの名前が異なるため、統一されたインターフェースのAdapterを使わないと、ハードコードされた型判定が追加されることになります。そのため、Handlerの各タイプに対応する一連のAdapterをカプセル化することで、 DispatcherServletはHandlerを通して適切なAdapterを直接検索することができます。 もちろん、AdapterのリストはBeanの初期化処理中にプリロードされるため、 基本的にはマッチするタイプを繰り返し検索することに変わりはありませんが、 書き方や設計の面では、I if文のセットを直接使用するのとは異なります。I if文の集合を直接使って判定する方法とは、書き方や設計に若干の違いがあります。
JPAでもJpaVendorAdapterはアダプタであり、JPAプロバイダによって異なるアダプタを実装する必要があります。多くのハンドラがありますが、アクセスの統一されたメソッドがあります。たとえば、HandlerAdapter の handle() メソッドです。典型的なソケットの例も、入力電圧が220Vであろうと110Vであろうと、最終的に必要なのは5Vですが、これはアダプタで変換する必要があります。
デザインパターンは太極拳の剣のようなもので、構えに固執せず、力まず、意思を持って、今後の開発プロセスでは、まだゆっくりと経験する必要があります。
