GoF以外のデザインパターン 3

関連するパターン

関連するパターン

 前ページで説明したように、Before/Afterパターン自体のコーディングはとてもシンプルですが、適用するクラスやオブジェクトの数が多いと、同じような記述をたくさん行うことになり、後々のメンテナンスが大変です。

 保守性を高める一方で、将来の変化に柔軟に対応できるようにBefore/Afterパターンを適用するためには、以下のように、ほかのパターン(GoFパターン)と組み合わせることが有効です。

・Template Methodパターン
 Template Methodパターンは、スーパークラス(図2のAbstractクラス)にTemplate Method(処理の枠組みとなるメソッド)を定義しておいて、詳細の実装はサブクラス(図2のConcreteクラス)に記述するパターンです。

 このTemplate Methodの中にBefore/Afterパターンを記述し、サブクラス側でbefore()、method()、 after()を実装させることによって、Before/Afterパターンを簡単なフレームワークで実現することができます(図2の左側)。

 メソッドのスコープについては、Templateメソッドはpublicですがそれ以外はprotectedになっているので、クライアント側からはTemplateメソッドだけが見え、Before/Afterパターンに従ってサブクラスの実装が呼び出されるようになるのです。

Adaptorパターン

 新しいソフトウエアを作る場合において、Before/Afterパターンをたくさんのクラス・オブジェクトに適用するのであれば、Template Methodパターンを使って設計することが有効です。

 ただし、既存のアプリケーションの拡張や、ほかから提供されたAPIを利用する場合において、Before/Afterパターンを後から適用するような場合には、Adaptorパターンのほうが向いています。

 Adaptorパターンでは、既存の実装(図2のAdapteeクラス)に対して、新たにAdaptorクラスを追加します。このAdaptorクラスは、既存の実装を覆って隠してしまう、一種のラッパークラスです。

 Adaptorクラスには、before()、targetMethod()、after()の3つのメソッドがあり、targetMethod()の中にBefore/Afterパターンを記述します。これにより、クライアント側からはtargetMethod()だけが見えた状態で、既存の実装(Adaptee)に対してBefore/Afterパターンを適用することができるのです。

この記事のキーワード

この記事をシェアしてください

人気記事トップ10

人気記事ランキングをもっと見る