Template Method(テンプレートメソッド)パターン

今回は、Template Methodパターンのお話です。

このパターンは、ソフトウェア開発での、自然で単純なテクニックを表しています。
継承とポリモーフィズムをご存知なら、誰でも思いつくようなことです。
ですので、ソフトウェア開発者の方なら、「ああ、そんなかんじのことは既にやったことあるよ」と思われる方も多いかと思います。

ただ、これを自ら、オブジェクト指向開発で頻繁に発生する一定のパターンとして、改めて捉えていらっしゃる方は、少ないのではないでしょうか。
パターンを捉え、それに名前をつけることが大事なのです。
それによって、漠然とやっていたことが、独立した概念となります。
概念に名前がつき、それが単語となって、コミュニケーションを高度化させることにつながっていくのです。

コンテンツ

1. 前置き: メソッドとは
2. 披露宴のテンプレート
3. ソフトウェア開発者の方のための追記
4. オススメ

前置き: メソッドとは

まず、ソフトウェア開発者でない方のために、メソッドとは何かということを、お話ししておきます。
メソッド(method)とは、英語で方法という意味です。
ソフトウェア開発では、クラスの振る舞いをプログラムコードに表現したものをメソッドと呼びます。
ソフトウェアにおいて、ある振る舞いを、具体的にはどういう方法で実行するのかということを表現しているからです。
ただし、プログラミング言語によっては、違う呼び方をするものもあります。

記事Top

披露宴のテンプレート

さて、テンプレートメソッドとは、スーパークラスがメソッドの大筋を持っていて、場合によって内容が違ってくる部分だけ、サブクラスが持つというパターンです。
たとえば、結婚披露宴の式次第を考えてみて下さい。
披露宴の式次第と一口に言っても、披露宴にはいろんなものがあります。
ド派手なものから質素なものまでいろんなランクがありますし、また地方によって、細かい慣習が違ったりします。
東京には、いろんな地方出身の方がいらっしゃいますね。
では、東京の式場って、日本全国の慣習それぞれについて、ド派手なものから質素なものまで、式次第が全部取り揃えてあるのでしょうか？
だとすると、大変な数になりそうですね。
私は式場関係者ではないので、絶対とは言えませんが、それはきっと違うと思います。
ちょっと、基本的な式次第ってのを考えてみましょう。

1. 開宴の挨拶
2. 新郎新婦入場
3. 来賓祝辞
4. ケーキ入刀
5. 乾杯
6. お色直し
7. 祝電披露
8. 祝辞
9. 余興
10. キャンドルサービス
11. 花束贈呈
12. 両家代表挨拶
13. 新郎新婦挨拶
14. 新郎新婦退場
15. お開き

こんなかんじでしょうか。
これ、オプションでちょっと付け足すことはあるかもしれませんが、基本的には、全ての披露宴で共通です。
では、どうやっていろいろな披露宴の違いを出すのでしょうか？
たとえば「新郎新婦入場でゴンドラを使うかどうか」だとか「祝辞を言う来賓の偉さ」、「入刀するケーキの大きさ」、「披露する祝電の数」、「お色直しで着てくるドレスの豪華さ」などなど…。
式次第が変わるのではなく、それぞれの内容が変わるのです。
では、式次第はこれでいいとして、内容は全ての式について、いちいちばらばらに決めるのでしょうか？
違いますね。
代表的なタイプの披露宴の内容が、セットになって提供されているのが普通です。
なんとかプランとかなんとかパックとか、ありますよね。
たとえば、「リーズナブルプラン」「セレモニーパック」「ゴージャスプラン」みたいな。
これこそが、テンプレートメソッドパターンです。
抽象スーパークラス「結婚式」の、「披露宴」というメソッド。
そしてサブラクラスである「リーズナブルプラン」「セレモニーパック」「ゴージャスプラン」。
披露宴メソッドは、式次第という大筋を持っています。
この大筋が、テンプレートなわけですね。
式次第の中には、「新郎新婦挨拶」みたいな、どんな披露宴でも変わらないものがあります。
こういうのについては、結婚式スーパークラスで、内容が決められています。
プランによって変わるものは、各プラン サブクラスが内容を決めます。
こんなふうに、基本的なやり方があって、そこからいろんなやり方が派生しているようなものは、テンプレートメソッドパターンで捉えることができます。
披露宴の式次第の他にも、基本的なやり方があって、それをちょっと変えると他のことができるってこと、ありますね。
料理の手順で、「ここでこれしてああすると、違うものができる」とか。
そういうものには、実はテンプレートがあるんだと考えると、そういうもの同士の関係が、はっきり整理できるのではないでしょうか。

記事Top

ソフトウェア開発者の方のための追記

テンプレートメソッドは、スーパークラスに作った主体となるメソッドから、抽象メソッドを呼ぶカタチで実装するのが一般的でしょう。
サブクラスは、必ずその抽象メソッドをオーバーライドすることになります。
その抽象メソッドが、つまり場合によって内容が違ってくる部分なわけです。
ところで、テンプレートメソッドパターンを、単なる共通処理のくくりだしと捉えることは、危険です。
このパターンは、スーパークラスとサブクラスという、継承階層を必要とします。
しかし、これは処理のくくりだしのための継承階層を作る必要があるということではありません。
そういった継承階層を常習的に作っていると、ユーティリティ的なクラスのような、ビジネスプロセスには存在しない、作為的なオブジェクト―不自然なオブジェクトを量産する(あるいは肥大化させる)ことになります。
そういうオブジェクトは、システムを理解しづらい複雑なものにしがちです。
他の側面から見ても、必然としてあらわれる継承階層を利用して、このパターンを使用するべきです。
最後に、おもしろい指摘を一つ。
このテンプレートメソッドでの、スーパークラスのメソッドと、それに呼ばれるサブクラスのメソッドの関係って、ユースケースのextendされる方とする方の関係に似ていませんか？
extendされるユースケースって、拡張ポイントを持ってますよね。
それが、テンプレートメソッドでの抽象メソッドなわけです。
うまく設計され、よく実装されたアプリケーションシステムは、一般にフラクタルな構造を持ちます。
ですので、オブジェクト指向による設計や実装でも、フラクタルちっくなものによく出会います。
これも、その一例です。

記事Top

オススメ

システムエンジニアの戯言というブログのオブジェクト指向言語を利用するメリットについて考えてみる ～ オブジェクトの多態性・・・第三章という記事では、クラス図とJavaっぽい擬似コードによるサンプルコードを使用して、テンプレートメソッドパターンを説明されています。
テンプレートメソッドパターンを使用して実装されたクラスを使う場合、そうでないクラスを使う場合の、クライアント側からみた利点も説明されています。

基礎編でオブジェクト脳のつくり方を繰り返しオススメしたように、デザインパターンではオブジェクト指向における再利用のためのデザインパターンを繰り返しオススメします。 デザインパターンといえば、この本に書いてあるものを指すからです。 下にあるように、他にもデザインパターンの本はいろいろあります。 しかし、他のデザインパターンに関する本は、この本の内容を解説しているんです。 だから、まずはこの本をお読みになることをオススメします。 この本にプラスして、あなたにあった他の本をお読みになるのが、効果的だと思います。

記事Top