Templete Method

GoFのパターンの一つTemplete Methodパターンだが、個人的にはこのパターンをそのまま使うことに恐怖を感じる。
例えば、次の例。

aaaaaaaaaaaa
(処理A)
bbbbbbbbbbbb
cccccccccccc
(処理B)
dddddddddddd

処理ごとに適切な文字列を出力すると思ってください。
その前後はa/b/c/dの文字列を出力する作業が共通なので、Templete Methodパターンの抽象クラスとして渡されることが考えられるでしょう。
ここで、b/cの間にxxxxxx...という文字列を入れたいという(新たな流動的要素を扱う)要求があるとします。そのためにはもちろん、元のクラスを変更しなければなりません。
自分で作成したときは別によいのですが、フレームワークなどでTemplete Methodが提供される場合、元のクラスに手を加えられないので、かゆいところに手が届かない仕様になりかねません。
こういった変更不可能なライブラリとしてTempleteMethodを提供する場合、上に一枚インタフェースをかませるという方法を取るとうまくいきます。

-








































(ライブラリ内)
User -> Executant(interface)[void execute()]
TempleteMethod(abstract class) implements Executant

















































































-

ライブラリの使用者は、基本的にはTempleteMethodのクラスを継承して処理を実装する。具体的な実行処理手順はexecute内に記述する。これで対応できなくなった場合、Executantを自前で実装することで、TempleteMethodにする時に扱われなかった新たな流動的要素を扱えるようになる。

最初に完全に流動的要素の洗い出しができてればいいんだけれど、洗い出せないことがほとんどだから、変更不可能なものを提供する場合はこの程度の回避策は用意してほしい気がする。